cz3 reszta-ref, Cele rozdziału


IV. BASIS

BASIS (BPCS Client/Server Advanced Systems Implementation Strategy) jest własną, pełną metodologią System Software Associates, (SSA') do wdrażania oprogramowania Business Planning and Control System (BPCS Client/Server). Pełna metodologia jest formalnym procesem wdrażania nowego systemu w organizacji, począwszy od opracowania wymagań organizacji a skończywszy na konserwacji i wsparciu utrzymywania nowego systemu.

1. Elementy systemu informatycznego zarządzania.

Pięć kluczowych składników systemu informatycznego zarządzania:

0x01 graphic

Proces przetwarzania danych tradycyjnie skupiał się jedynie na sprzęcie, oprogramowaniu i danych. Brak zintegrowania tych komponentów z personelem, strukturą organizacyjną,

procedurami i sterowaniem, jest główną przyczyna nieudanych wdrożeń. Natomiast metodologie cyklu życia włączając BASIS używają wszystkich pięciu składników.

Dostarczenie nowego systemu oznacza instalację :

Wdrożenie nowego systemu to dodatkowo:

2. Cykle życia wdrożenia

Cykl życia wdrożenia jest formalnym procesem wdrożenia nowego systemu informatycznego zarządzania w organizacji. Cykl ten rozpoczyna się od zbadania wymagań poprzez utrzymanie i wspomaganie nowego systemu. Podstawowe fazy cyklu życia systemu zostały rozszerzone o dwie dodatkowe fazy:

W praktyce metodologie oparte na cyklu życia są wykorzystywane przez duże organizacje wdrażające duże systemy. W rezultacie są one często niewygodne, czasochłonne i obarczone papierkową robotą.

4. Korzyści BASIS.

Misją firmy SSA (System Software Associates) jest dostarczenie konkurencyjnej metody efektywnego wdrożenia BPCS/CS. Metodologia BASIS zapewnia efektywne wdrożenie BPCS. Pozwala ona klientom na osiągnięcie rezultatów jakich oczekiwali oraz na uświadomienie pełnych

korzyści zainwestowania w system informatyczny. 0x01 graphic

Są trzy główne korzyści zastosowania metodologii BASIS:

a) Definicja projektu

W metodologii BASIS proces wdrożenia BPCS opiera się na metodzie top-down. Poręczenie dla nowego systemu pochodzi od naczelnego kierownictwa, które ma:

Całkowite wdrożenie projektu jest uzgodnione, jasno zdefiniowane w Project Definition Memorandum przed podjęciem jakichkolwiek szczegółowych działań.

b) Definicja wymagań systemu

Metodologia BASIS definiuje wymagania systemu poprzez połączenie edukacji i technik strukturalnych. W szczególności :

c) Efektywne zarządzanie projektem

Zarządzanie projektem składa się z planowania, organizowania, kierowania i kontroli projektu.

projektu. Opis ról, macierz czynności ról, macierz substytucyjności ról oraz wykres standardowej organizacji projektu ułatwiają proces organizowania projektu.

8. Tradycyjne podejście

Tradycyjne podejścia nie używają formalnych metodologii cyklu życia co powoduje wiele problemów :

Każdy z tych efektów powoduje niezadowolenie użytkownik z nowego systemu. Wszystkie wymagania przedsięwzięcia mogą zostać osiągnięte poprzez rozwiązanie tych problemów czemu stara się podołać metodologia BASIS.

9. Składniki BASIS

Są cztery składniki BASIS:

Technika strukturalna jest metodą lub narzędziem używanym przez jedną bądź więcej osób z zespołu projektowego dla przyspieszenia skompletowania jednej lub więcej czynności. Strukturalne techniki maja największe osiągnięcia w obszarach analizy projektowania i rozwoju systemu.

Rola to osoba albo grupa osób która wykonuje jedno lub więcej zadań składających się na czynność i która przygotowuje jedno lub więcej produktów gotowych BASIS.

Czynność jest grupą zadań które muszą być wykonane, aby przeprowadzić projekt przez jego cykle życia i które bezpośrednio lub pośrednio wytwarzają końcowe produkty.

Produkt końcowy- jest namacalnym produktem lub grupa czynności kompletowanych w określonej kolejności.

0x01 graphic

Rys Komponenty BASIS

a) Czynności i zadania

Czynności i zadania definiują co musi być zrobione na każdym etapie projektu.

Czynności są fundamentem do planowania projektu od momentu kiedy wykorzystują czas i zasoby do realizacji projektu. Niektóre czynności BASIS są rozbite na szczegółowe zadania które umożliwiają wprowadzenie danych i testowanie systemu.

Identyfikacja czynności i zadań:

0x01 graphic

Zależności czynności i zadań

Rozpoczęcie czynności albo zadania może zależeć od skończenia jednej lub więcej poprzedzających czynności. Zależności te definiują porządek wykonywania czynności i zadań polecany przez metodologię BASIS.

Poprzednik jest czynności która musi zostać rozpoczęta lub zakończona przed tym jak następująca po niej czynność rozpoczyna się lub kończy.

Następnik jest czynnością która nie może się rozpocząć lub skończyć dopóki jej poprzedzające czynności nie zostaną rozpoczęte lub zakończone.

Zależność jest relacją pomiędzy czynnością i jej poprzednikiem. Zależności są przedstawiane wizualnie jako diagramy przepływu czynności. Każda zależność jest pokazana za pomoc a strzałki pomiędzy dwoma czynnościami skierowanej w stronę następnika.

W metodologii BASIS występują trzy rodzaje zależności:

Diagramy przepływu czynności

Czynności są identyfikowane poprzez numer czynności i mogą mieć wiele poprzedników i następników. Czynności nie muszą być wykonywane w kolejności swojej numeracji.

Np. dwie czynności mogą być wykonywane równolegle. Diagramy przepływu czynności są podzielone na trzy obszary:

Kółka oznaczają czynności przygotowawcze

Kwadraty oznaczają czynności

Trójkąty oznaczają czynności sprawdzające i zatwierdzające oraz czynności zapewnienia jakości :

0x01 graphic

b) Produkt końcowy

Produkt końcowy - definiują co jest stworzone na każdym etapie projektu. Metodologia BASIS jest procesem skierowanym na produkt końcowy dostarczający krótkoterminowych celów projektu. Każdy produkt końcowy BASIS jest sprawdzany przez zarząd. Produkty końcowe BASIS należą do czterech kategorii:

c) Role

Role definiują kto wykonuje każdą czynność definiując bardziej zaangażowanie w projekt niż nazwy prac. Role mogą być przyporządkowane indywidualnym osobom albo grupie osób.

Przykładowo:

Z wymienionych 27 ról metodologii BASIS 13 może być wykonywanych przez osoby z zewnątrz z których 7 może być pracownikami SSA, podczas gdy pozostałe 13 ról jest zwykle wykonywane przez pracowników danej firmy. Spośród wszystkich ról użytkowników tylko jedna (kierownik przetwarzania danych) jest stanowiskiem pracy, natomiast reszta jest specyficznymi rolami projektu.

Każda rola jest unikalnie identyfikowalna przez standardowy skrót składający się zarówno z małych i dużych liter.

Tabela Basis roles

Odpowiedzialność i wspomaganie ról

Każda faza, produkt końcowy i czynność w metodologii BASIS ma odpowiedzialną za siebie rolę. Ta rola jest odpowiedzialna za:

Dodatkowo każda faza lub czynność ma jedna lub kilka ról wspomagających, które asystują w realizacji czynności.

Zespół projektowy

Zespół projektowy składa się ze wszystkich osób pracujących nad projektem wdrożenia BPCS.

Steering Committee (Komitet sterujący)- jest ciałem podejmującym decyzje o :

Kilku lub wszyscy Area Managers mogą być również członkami komitetu sterującego.

Project Director- jest najważniejszą indywidualną rolą w metodologii BASIS, ponosi on główną odpowiedzialność za sukces projektu i za kierowanie codzienną pracą nad projektem. Musi on posiadać predyspozycje oraz autorytet odpowiednie do zasięgu i skali projektu.

Account Executive - jest starszym konsultantem przedsięwzięcia który asystuje przy rozwoju ogólnego planu projektu, definiując krytyczne cele projektu i zapewniając że wszystkie te krytyczne cele zostaną osiągnięte po wdrożeniu. Współpracuje on z Executive Sponsor i Project Director.

Engagement Manager- jest on doświadczonym konsultantem do spraw zastosowań , który asystuje kierownikowi projektu w codziennej pracy oraz jest zaangażowany w szczegółowe planowanie projektu, alokacje zasobów, definiowanie wymagań, edukację , analizy , projektowanie i testowanie systemu.

Area Manager- jest jednostką odpowiedzialną i mająca zwierzchność nad specyficznym obszarem przedsięwzięcia na który ma oddziaływać wdrożenie BPCS. Może on być operational vice president, departamental manager, albo dyrektorem.

Key users (kluczowi użytkownicy) - są indywidualnymi osobami odpowiedzialnymi za specyficzne obszary funkcjonalne w organizacji. Może to być np. : Accounts Receivable Supervisor, Stock Room Supervisior lub Order Entry Supervisor.

Rys Project Team

d) Techniki strukturalne

Dobre techniki komunikacji są osiągane poprzez stosowanie technik strukturalnych. Techniki strukturalne są samodokumentującymi się metodami, które w szczególności :

Strukturalne techniki są również uważane za najlepsze obecne metody praktyczne przy wdrażaniu systemów.

Sześć kategorii technik strukturalnych:

18. Plany projektu

Plany projektu pomagają stworzyć kosztorys i harmonogram głównych faz projektu, powiązanych z nimi czynności oraz szczegółowych zadań. Jest jeden plan dla całego projektu. Jest on przygotowany na takim poziomie szczegółowości aby uwzględnić każdy segment i kluczowe produkty końcowe.

Wymagania co do zasobów- są całkowitymi oszacowaniami na podstawie segmentów i kluczowych produktów końcowych. Są one prezentowane na takim poziomie szczegółowości który uwzględnia całkowity czas wszystkich zewnętrznych i wewnętrznych zasobów. Nie pokazują one czasu poświęconego na dane jednostki. Plan projektu zawiera zbiorczy kosztorys, w który włączone są wszystkie koszty SSA oraz pozostałe. Przykładami pozostałych kosztów są sprzęt komputerowy który nie został dostarczony przez SSA oraz bezpośrednie koszty personelu danej organizacji zaangażowanego w projekt.

Istotny plan projektu jest przygotowywany po szczegółowym zbadaniu obecnej sytuacji klienta, wymagań danego przedsięwzięcia, celów i miar. Wszystko to powoduje , że zostają zebrane wystarczające informacje do stworzenia rozsądnych planów i oszacowań. Rewizja planu projektu jest obowiązkowa po prototypowaniu i zdefiniowaniu wymagań. Robi się to po to aby poznać zasięg wszystkich zmian oprogramowania, procedur i sterowania. Projekt oprogramowania musi być sprawdzany przy każdym kamieniu milowym, jeżeli komitet sterujący lub Account Executive uważa to za konieczne. Ogólny stan projektu jest przeglądany w momencie sprawdzania i zatwierdzania kluczowych produktów końcowych (przy każdym kamieniu milowym). Przegląd ten pozwala na ustalenie czy projekt jest zgodny z harmonogramem i kosztorysem. Stan projektu może być sprawdzany częściej jeżeli komitet sterujący lub Account Executive uważa to za konieczne. Np. przegląd stanu projektu może być włączony w agendę regularnych spotkań komitetu sterującego.

19. Kamienie milowe

Kamień milowy - zaznacza zrealizowanie znaczącej części projektu. Kamienie milowe nie są czynnościami , nie pochłaniają czasu ani zasobów projektu. Są one zdarzeniami.

Rys

Tabela

20. Plany następnych kamieni milowych

Plan następnego kamienia milowego jest rozszerzenie planu projektu do poziomu szczegółowości czynności, nie zawiera on zadań które mają być zrealizowane podczas każdej czynności. Dla każdego składnika planu projektu jest sporządzany osobny NMP. Plan zatrudnienia dla każdej czynności pokazuje czas oszacowany za pomocą ról jak również liczbę osób na rolę potrzebnych do zrealizowania czynności zgodnie z harmonogramem. Np. Jeżeli jest potrzebne 80 godzin na pianie kodu, a czynność jest zaplanowana na 1 tydzień to znaczy że potrzebujemy dwóch pełnoetatowych programistów. Przypisanie ról identyfikuje rolę odpowiedzialności wspomagania i określony personel SSA lub danej organizacji przeznaczony do pełnienia tych ról. Każdy kluczowy produkt końcowy zawiera NMP w celu osiągnięcia następnego kamienia milowego projektu. W momencie zatwierdzenia kluczowego produktu końcowego przez komitet sterujący zostaje zatwierdzony NMP dla następnego kamienia milowego. Zatwierdzenie NMP przez komitet sterujący angażuje wewnętrzne i zewnętrzne zasoby w celu osiągnięcia następnego kamienia milowego. Postęp

względem planu jest sprawdzany na każdym posiedzeniu komitetu sterującego. To daje możliwość komitetowi sterującemu na podjęcia działań korygujących.

V. BASIS - Metodologia wdrażania BPCS

Korzyści z systemów planowania i kontroli takich jak BPCS Client / Server obejmują:

zmniejszenie zapasów magazynowych;

• wyższą jakość produkcji przez lepsze planowanie;

lepsze użytkowanie aktywów;

lepszą obsługę klienta ,

usprawnienie kontroli kosztów.

Powyższe korzyści nie są osiągane poprzez zakup czy instalację systemu, ale jedynie poprzez wdrożenie systemu w organizacji. Metodologia wdrożenia BASIS jest opracowana tak aby wdrożenie systemu BPCS Client/Server zakończyło się powodzeniem najwcześniej jak to jest tylko możliwe.

Projekty wdrażania systemu maj ą istotny wpływ na zarządzanie i sposób postępowania w organizacji.

Wprowadzenie systemu formalnego, takiego jak BPCS, oznacza zmiany dla:

metod planowania;

metod kontroli;

polityki;

procedur;

opisów zadań; oraz,

struktury organizacyjnej.

Szeroki zakres BPCS Client/Server ma wpływ na niemal wszystkie operacyjne działania przedsiębiorstwa w produkcji oraz dystrybucji, od planowania na szczeblu zarządu, a skończywszy na zadaniach pracowników biurowych.

Zmiany w sposobie zarządzania w całej organizacji wymagają zaangażowania i przeznaczenia znacznych zasobów przez wiele miesięcy. Pomyślne wdrożenie wymaga metodologii, by osiągnąć żądane rezultaty poprzez sprawne zarządzanie zasobami.

BASIS został opracowany by wspomagać wdrożenie zmian w sposobie zarządzania, w możliwie krótkim czasie i przy możliwie niskich kosztach.

FAZY BASIS

BASIS składa się z następujących faz:

FAZA m0 - PRZEDWDROŻENIOWA FAZA ANALIZY MIGRACJI

FAZA 0 - ASEKURACJA SYSTEMU

FAZA I - DEFINICJA PROJEKTU

FAZA II - PRZYGOTOWANIE WDROŻENIA

FAZA III - ROZWÓJ I ZATWIERDZENIE SYSTEMU FAZA

FAZA IV - WDROŻENIE

FAZA V - UŻYTKOWANIE NOWEGO SYSTEMU

Pięć plus dwie fazy metodologii BASIS pokrywają wszystkie elementy cyklu życia BASIS, włącznie z dwoma fazami przedwdrożeniowymi.

FAZA m0 - PRZEDWDROŻENIOWA FAZA ANALIZY MIGRACJI

Proces migracji istniejącego systemu do nowych technologii (lub rozwijającej się technologii). Może być bardzo chaotyczny nawet w najlepszym środowisku. Wraz z wypuszczeniem linii produktu BPCS Klient - Serwer, SSA zmienia podstawową technologię i architekturę która w znacznej mierze zmienia sposób w jaki system może być skonfigurowany i użytkowany przez klientów. Klienci mają tera możliwość zmieniać fizyczne warstwy w swojej infrastrukturze. Faza ta zapewnia że ci użytkownicy którzy przygotowują się do migracji nowej lub rozwijającej się technologii rozwijają strategię. Podejście migracji do systemu BPCS Klient - Serwer rozwinęło się przy użyciu „najlepszej metody” jak również określonych zadań koniecznych do zapewnienia pomyślnej migracji. Metodologia BASIS została udoskonalona o zbiór wytycznych, produktów końcowych oraz prostych przykładowych planów pracy, co pomaga w pomyślnym wdrożeniu projektu w tym zakresie. Dlatego celem tej fazy jest zidentyfikowanie „czynników gotowości do migracji” danego klienta oraz istotna definicja projektu migracji. Podczas tej fazy jest również dokumentowany potencjał Business Process Re- Engineering'u. Plan czynności fazy m0 nakreśla ogólne wymagania dla określenia typowej metody upgradu preferowanej przez klienta.

Faza m0- analiza możliwości migracji

High Level Management Report (HLMR)

Przegląd obecnych strategii biznesu oraz określonych nakładów wynikających z upgrade'u.

Current Systems Architecture Report (SAC)

Definiuje istniejącą topologie sieci, architekturę systemu, standardy i procedury oraz personel.

Current Hardware Configuration Report (CHC)

Kataloguje krytyczny sprzęt ze wszystkich stanowisk.

Current Software Configuration Report (CSC)

Kataloguje krytyczne oprogramowanie będące w użyciu zarówno przez BPCS jak i nie.

Client Timing Analysis (CTA)

Ustala nakłady czasu i ograniczenia.

Client Skills Mix (CSM)

Definiuje obecne umiejętności techniczne użytkowników.

Business Environment Report (BER)

Pozwala na zrozumienie obecnie użytkowanych systemów biznesowych.

Migration Definition Analysis Report (MDAR)

Opisuje nowe przedsięwzięcie I system IT oraz kluczowe cele.

Migration Risk Assessment Document (MRA)

Identyfikuje i szacuje czynniki gotowości do uzyskania celów migracji dla wszystkich części systemu.

Tabela: Produkty końcowe Fazy m0.

FAZA 0 - ASEKURACJA SYSTEMU

Celem tej fazy jest znalezienie propozycji rozwiązań. Aby to osiągnąć Account Executive musi poświęcić czas na zrozumienie wymagań klienta oraz proponowanego zakresu projektu, aby móc oszacować wysiłek i czas potrzebny do realizacji projektu. Podczas tej fazy wiele czynności jest wykonywanych przez reprezentantów sprzedawcy oraz członków ich zespołu (łącznie z ekspertami do spraw przedsprzedaży). Te czynności nie są zdefiniowane ani opisane w metodologii BASIS. Zdefiniowane są tylko te czynności które mają być wykonywane przez Account Executive. Faza 0 rozpoczyna się gdy reprezentant sprzedawcy przedstawia Account Executiv'a przyszłemu klientowi. Account Executive musi się jednak wcześniej zapoznać z informacjami zebranymi w trakcie obserwacji cyklu sprzedaży. Account Executive powinien posiadać wiedzę na temat każdej alternatywy czynności przedsprzedażowych metodologii BASIS, które mogą być przydatne do rozszerzenia i polepszenia sprzedaży. Racjonalne uzasadnienie zaadoptowania tych alternatyw musi zostać dokładnie przedyskutowane. Account Executive powinien przyjść do 2klienta i przeprowadzić wywiad ze sponsorem i dyrektorem projektu, aby ustalić wyniki przedsięwzięcia, przyszłe możliwości, cele strategiczne oraz kluczowe wyniki zarządzania. Ogólne, racjonalne uzasadnienia cyklu życia metodologii BASIS powinny być zaprezentowane sponsorowi i dyrektorowi projektu. Propozycje rozwiązań metodologii BASIS powinny zawierać wkład różnych członków SSA co do dostarczanych przez SSA rozwiązań. Propozycje muszą zostać uzgodnione z Account Executive'm i reprezentantem sprzedawcy w formie dokumentu propozycji sprzedaży SSA. Następnie dokument ten jest prezentowany klientowi przez Account Executive. Osiągnięcie konsensusu co do propozycji przedstawionych w dokumencie pozwala w rezultacie na przejście do następnej fazy projektu. Przedostatnim krokiem jest dążenie do asekuracji systemu. Składa się on z dwóch komponentów:

Wyjściem jest dokument SP (Propozycja sprzedaży) oraz SAR (Asekuracja systemu i analiza ryzyka). Faza 0 kończy się wykonaniem BPCS Client/ Server Software License Agreement (SLA),Professional Services Agreement (PSA) and initial Engagement Authorisation (EA) pomiędzy SSA i klientem.

Czynność

Opis

Osoba odpowiedzialna

0.1

Account Executive Orientation

AcctEx

0.2

Site Visit

AcctEx

0.3

BASIS Presentation

AcctEx

0.4

BASIS Solution Proposal, Sales Proposal (SP)

AcctEx

0.5

Systems Assurance & Risk Analysis ( SAR).

AcctEx

0.6

Contract Review

AcctEx

Tabela: Czynności Fazy 0

Faza 0 - Asekuracja systemu

Basis Presentation

Przedstawia rozwiązania BASIS powstałe na podstawie analizy wizyt u klienta, które mają zostać wcielone do SSA Sales Proposal.

Sales Proposal (SP)

Opisuje obecne procedury oraz identyfikuje obszary które potrzebują ulepszenia.

System Assurance/Risk Analysis (SAR)

Zapewnia, że Sales Proposal jest adekwatna do potrzeb i oczekiwań klienta oraz, że ryzyko wszystkich części jest możliwe do zaakceptowania.

Tabela: Produkt końcowy Fazy 0

FAZA I DEFINICJA PROJEKTU

CEL

Celem fazy definicji projektu jest określenie celów strategicznych projektu, przedmiotu i miar, oraz określenie pełnego zakresu nowego systemu, harmonogramu i budżetu.

ROZPOCZĘCIE

Faza 1 rozpoczyna się, gdy Zatrudniony Menedżer (EngMgr) jest przedstawiony Sponsorowi Projektu i Szefowi Projektu. (ProjDir).

ZAKOŃCZENIE

Faza 1 kończy się raportem i zatwierdzeniem Definicji Projektu (PDM).

KROKI BASIS:

    1. Analiza

    2. Spotkanie Wykonawcze

    3. Wybór Zespołu Projektowego

    4. Analiza i Plan Szkoleń

    5. Szkolenia - Planowanie i Kontrola Zasad

    6. Raport Definicji Projektu

OPIS SZCZEGÓŁOWY

Faza definicji projektu składa się z następujących kroków:

Analiza działań w przedsiębiorstwie dostarcza szczegółowych informacji, na bazie których, ustala się zakres projektu, cele strategiczne, przedmiot i miary, a przede wszystkim harmonogram i budżet.

Wybór członków zespołu określa wszystkie osoby, które będą pełniły kluczowe role w projekcie. Są to m.in. Komitet Sterujący (SteerCom), Komitet Polityczny (PolComm), Szef Projektu (ProjDir), Zatrudniony Menedżer (EngMgr), Kierownik Przetwarzania Danych (DPMgr), Menedżer Dziedzinowy (AreaMgr) i Kluczowi Użytkownicy (KeyUsr).

Spotkanie wykonawcze służy jako forum, potwierdzające korzyści i koszty nowego systemu, dochodzi się na nim do wspólnego porozumienia odnośnie celów i miar projektu, określa potrzeby planowania i szkolenia oraz ustala Plan Projektu.

Przygotowanie Planu Szkoleń (EP) określa zakres, harmonogram, budżet i uczestników, począwszy od planowania zasad szkolenia wysokiego szczebla, a skończywszy na szkoleniu użytkowników końcowych.

Szkolenie Planowanie i Zasady Kontroli (PCPE) określa podstawy wdrożenia nowego systemu wśród Menedżerów Dziedzinowych AreaMgr, jeżeli nie znają oni tych podstaw.

Raport (PDM- przegląd i Zatwierdzenie Definicji Projektu) określa uzgodnienia i zaangażowanie w cele kluczowe projektu, zakres nowego systemu, funkcje wykonywane przez nowy system oraz elementy do przeniesienia z systemów istniejących i plan określenia wymagań

Końcowym celem fazy definicji projektu jest uzyskanie porozumienia i zaangażowania w projekt. Projekty słabo określone mają mniejszą szansę powodzenia niż te, które są dobrze określone. Powodzenie zależy również od stopnia bezpośredniego odniesienia projektu do celów strategicznych przedsiębiorstwa i stałego sprawdzania postępu w stosunku do celów.

FAZA II PRZEGOTOWANIE WDROŻENIA

CEL

Celem fazy przygotowania wdrożenia jest instalacja standardowego oprogramowania BPCS Client/Server, szkolenie Menedżera Dziedzinowego (AreaMgr) przedsiębiorstwa i Użytkowników Kluczowych (KeyUsr) odnośnie użytkowania systemu oraz uzyskanie porozumienia co do wymaganych zmian w polityce, procedurach i kontroli w przedsiębiorstwie.

ROZPOCZĘCIE

Faza 2 rozpoczyna się spotkaniem wprowadzającym, w którym biorą udział wszyscy pracownicy, których dotyczy.

ZAKOŃCZENIE

Faza 2 kończy się przygotowaniem i zatwierdzeniem Mapy Wdrożenia Systemu (SIM).

KROKI BASIS:

2.1 Spotkanie wprowadzające

2.2 Instalacja Produktu

2.3 Szkolenie „Koncepcje i Aplikacje"

2.4 Przegląd Polityki i Procedur

2.5 Przygotowanie Prototypowania

2.6 Szkolenie Zaawansowane n/t Produktów

2.7 Przeprowadzenie Prototypowania

2.8 Ustalenie Warunków Technicznych

2.9 Przygotowanie Mapy Wdrożenia Systemu

OPIS SZCZEGÓŁOWY

Faza 2 składa się z następujących kroków:

Na spotkaniu wprowadzającym przekazuj e się wszystkim w przedsiębiorstwie główne cele nowego systemu oraz informuje się zarząd o zaangażowaniu w zmiany w sposób, który pozytywnie wpłynie na udział każdego w projekcie;

Instaluje się na komputerze standardowe produkty i oprogramowanie BPCS Client/Server zakupione przez przedsiębiorstwo. Dodatkowo, ustala się procedury uzyskiwania wsparcie technicznego, sposób utrzymywania fizycznego bezpieczeństwa zbiorów oraz określa się dostęp użytkowników do oprogramowania;

Przegląd Polityki i Procedur (PPR) określa wszystkie obszary polityki i zasad, które powinny być zrewidowane w trakcie spotkań prototypowania dla dalszego

rozwoju, zmiany czy zachowania;

Spotkania Szkoleniowe „Koncepcje i Aplikacje" (C&A) mają na celu przekazanie Menedżerowi Dziedzinowemu (AreaMgr) i Użytkownikom Kluczowym (KeyUsr) wiedzy ogólnej na temat najistotniejszych produktów BPCS Client/Server.

Główny nacisk kładzie się tutaj na przepływ informacji pomiędzy aplikacjami.

Szkolenie C&A poprzedza udział w sesjach prototypowania;

Przygotowuje się szczegółowy plan przeprowadzania sesji prototypowania. Plan zawiera określenie terminologii, określenie scenariuszy planowania i kontroli, które muszą być przestrzegane w trakcie sesji. Uprzednio należy załadować dane i sporządzić listy wszystkich procedur, które muszą być sprawdzone. Zaleca się by polityka i procedury były opisane w raporcie PPR i byty włączone w Plan Warsztatów Prototypowania (PWP);

Sesje Zaawansowanych Szkoleń n/t Produktów BPCS Client/Server (APE) dają Menedżerowi Dziedzinowemu (AreaMgr) i użytkownikom Kluczowym (KeyUsr) szczegółową wiedzę na temat każdego z wdrażanych produktów BPCS Client/Server. Te sesje są wstępem do udziału w sesjach prototypowania;

Sesje prototypowania są forum, na których testuje się standardowe oprogramowanie BPCS Client/Server, porównując je z rzeczywistymi scenariuszami postępowania w przedsiębiorstwie, określonymi w PWP. Decyzje podjęte w trakcie tych sesji określają:

Decyzje są sprawdzone i zatwierdzone przez Komitet Sterujący (SteerCom) w raporcie (RDR), razem ze szczegółowym planem pracy do przygotowania Mapy Systemu Przedsiębiorstwa (BSM);

BSM zawiera plany pilotażu testowania dla nowych wymagań, określonych w raporcie RDR, w tym:

Zmiany w przedsiębiorstwie, procedury i kontrolę;

Automatyczne połączenia z systemami innymi od BPCS Client/Server;

Procedury ręcznej i automatycznej konwersji danych.

Tworzy się oddzielny BSM dla każdego obszaru działalności przedsiębiorstwa. Zatwierdzenie BSM przez Komitet Sterujący (SteerCom) zawiera zobowiązanie zaangażowania czasu i zasobów wymaganych w przygotowanie projektu koncepcji działalności przedsiębiorstwa (Faza 3);

Zapoznanie z warunkami technicznymi BPCS Client/Server uczy personel techniczny z architekturą i standardami BPCS Client/Server. Jest to konieczne tylko w przypadku, gdy personel ma być zaangażowany w wykonywanie zmian i modyfikacji w oprogramowaniu BPCS Client/Server.

Celem Fazy 2 jest stworzenie i zatwierdzenie harmonogramu wdrożenia w każdym z obszarów działalności przedsiębiorstwa oraz określenie szczegółowych specyfikacji zmian w strukturze organizacyjnej, procedurach i kontroli. Na koniec Fazy 2, przedsiębiorstwo powinno mieć pełne zrozumienie zasadności każdej ze zmian, jak również czasu i zasobów wymaganych by je wdrożyć.

FAZA III - ROZWÓJ I ZATWIERDZENIE SYSTEMU

CEL

Celem fazy rozwoju i zatwierdzenia systemu jest wykonanie wszystkich wymaganych zmian w standardowym oprogramowaniu BPCS Client/Server jak również dokonanie zmian w strukturze organizacyjnej, procedurach i kontroli. Zmiany te są zatwierdzane na sesjach pilotażowych.

W większości wdrożeń Faza 3 jest wykonywana wg oddzielnych harmonogramów dla poszczególnych obszarów (segmentów).

ROZPOCZĘCIE

Faza 3 rozpoczyna się wykonaniem zmian w oprogramowaniu, przedsiębiorstwie, procedurach i kontroli.

ZAKOŃCZENIE

Faza 3 kończy się Szkoleniem Użytkowników Końcowych (EUT).

KROKI BASIS:

3.1 Plan Jakości

3.2 Ustalenie Zmian w Oprogramowaniu

3.3 Ustalenie Innych Zmian

3.4 Przeprowadzenie Pilotażu

3.5 Szkolenie Użytkowników Końcowych

OPIS SZCZEGÓŁOWY

Faza 3 skład się z następujących kroków:

Dokonuje się wszystkich zmian w oprogramowaniu, strukturze organizacyjnej, procedurach i kontroli;

Testuje się oprogramowanie, procedury i kontrolę zgodnie z testami pilotażu wg Mapy Implementacji Systemu (SIM); oraz,

Menedżer Dziedzinowy (AreaMgr) przeprowadza sesje szkoleniowe Użytkowników Końcowych (EUT) celem zapoznania ich z działaniem nowego systemu, z jego procedurami i kontrolą.

Drugim celem kluczowym Fazy 3 jest przygotowanie szczegółowego planu przejścia na działanie z nowym systemem (Faza 4)

Na koniec Fazy 3, trzy lub cztery konieczne składniki systemu powinny mieć swoje stałe miejsce:

Sprzęt i oprogramowanie komputerowe;

Polityka przedsiębiorstwa, procedury i kontrola; oraz,

Przeszkolony personel.

Czwarty Składnik, Dane jest dodawany w Fazie 4.

FAZA IV - WDROŻENIE

CEL

Celem tej fazy jest upewnienie się, że przygotowane zostały procedury przedsiębiorstwa, personel i dane, przed przejściem na nowy system oraz że została dokonana konwersja danych statycznych i zmiennych.

W większości wdrożeń Faza 4 jest wykonywana wg oddzielnych harmonogramów dla poszczególnych obszarów (segmentów).

ROZPOCZĘCIE

Faza 4 rozpoczyna się sprawdzeniem stanu gotowości przedsiębiorstwa do pracy z nowym systemem.

ZAKOŃCZENIE

Faza 4 kończy się przejściem na nowy system.

KROKI BASIS:

4.1 Przygotowanie do Przejścia na Nowy System

4.2 Przejście na Nowy System

SZCZEGÓŁOWY OPIS SYSTEMU

Na koniec Fazy 4, wszystkie składniki nowego systemu są na miejscu dla bieżącego obszaru działalności przedsiębiorstwa:

Sprzęt i oprogramowanie komputerowe;

Polityka, procedury i kontrola w przedsiębiorstwie;

• Przeszkolony personel; oraz,

Dane.

FAZA V - UŻYTKOWANIE NOWEGO SYSTEMU

CEL

Celem tej fazy jest określenie przydatności nowego systemu i zapewnienie bieżącego wsparcia.

ROZPOCZĘCIE

Faza 5 rozpoczyna się monitorowaniem pracy z nowym systemem.

ZAKOŃCZENIE

Faza 5 kończy się podpisaniem umowy z firmą zapewniającą wsparcie pracy systemu i zatwierdzeniem przez przedsiębiorstwo Raportu Efektywności Systemu (SEM).

KROKI BASIS:

5.1 Uzupełnienia i Bieżące Utrzymanie

5.2 Ocena Rezultatów

SZCZEGÓŁOWY OPIS PRACY Z NOWYM SYSTEMEM

Kluczowym elementem Fazy 5 jest ocena wydajności nowego systemu w porównaniu do celów strategicznych zgodnie z dokumentacją zawartą w Raporcie Definicji Projektu (PDM). Sprawdzenie efektywności systemu powinno być wykonane 3-6 miesięcy po rozpoczęciu pracy z nowym systemem.

Drugim celem Fazy 5 jest określenie zakresu wsparcia ze strony partnera

serwisowego. Zawiera ono:

Pomoc użytkownikom;

Raportowanie i sposób rozwiązywania problemów;

Wdrożenie zmian procedur kontroli;

Zabezpieczenie sobie zmian w oprogramowaniu; oraz szkoleń.

13



Wyszukiwarka

Podobne podstrony:
Podstawy marketingu, marketing wykłady, Rozdział 1 - podstawowe pojęcia i cele marketingu- mix
cz3, ROZDZIA˙ I
CELE WYCHOWANIA rozdzial V Podmiotowość w wychowaniu
rozdzial 2 cz3(1)
Rozdzial 2 cz3, ## Documents ##, HTML 4 - Czrna księga WebMastera
CELE WYCHOWANIA rozdzial V Podmiotowość w wychowaniu
Andragogika rozdzial 1 cz3
System operacyjny UNIX dla poczatkujacych i zaawansowanych, rozdzial8 i reszta
Cele uzytkownikow portali VOD rozdzial 1
cele kopiarki
Metody i cele badawcze w psychologii
01 E CELE PODSTAWYid 3061 ppt
Podstawy zarządzania wykład rozdział 05
Istota , cele, skladniki podejscia Leader z notatkami d ruk
2 Realizacja pracy licencjackiej rozdziałmetodologiczny (1)id 19659 ppt
olejki eteryczne cz3
3 CELE KSZTAúCENIA
Ekonomia rozdzial III

więcej podobnych podstron