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:

• Sprzęt komputerowy

• Oprogramowanie

• Struktura organizacyjna, procedury i sterowanie

• Ludzie

• Dane

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ę :

• Sprzęt komputerowy, system operacyjny, oprogramowanie,

• Struktura organizacyjna, procedury i sterowanie

Wdrożenie nowego systemu to dodatkowo:

• Odpowiednio wyszkoleni ludzie do sterowania i użytkowania systemu

• Przekształcenie danych istniejących w organizacji na odpowiednie dla systemu

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:

• Faza m0 - Przedwdrożeniowa analiza migracji,

• Faza 0 - Asekuracja systemu.

• Przedwdrożeniowa analiza migracji - planowanie migracji z jednej wersji BPCS do innej.

• Asekuracja systemu - służy zapewnieniu, że SSA rozumie kroki jakie muszą zostać podjęte aby wdrożenie zakończyło się sukcesem, jest to w istocie faza przedsprzedażowa.

• Planowanie i analiza projektu - Faza ta rozpoczyna się od dokładnego zbadania celów i wymagań systemu, po czym następuje zdefiniowanie zadań w formie szczegółowej i sumarycznej, jak również nakreślenie fizycznego projektu systemu.

• Projektowanie - W wyniku tej fazy powstaje dokumentacja użytkownika oraz zbiorcza, szczegółowa techniczna specyfikacja systemu.

• Rozwój - programowanie i testowanie wszystkich programów

• Wdrożenie - przekształcenie danych i istniejących w organizacji na odpowiednie operacje systemu

• Przegląd efektywności ( faza audytu powdrożeniowego) - faza pomiaru stopnia w jakim system spełnia postawione mu cele

• Eksploatacja systemu - utrzymanie, modyfikacja i udoskonalanie systemu

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.

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

• jasna definicja projektu,

• właściwa definicja wymagań systemu

• efektywne zarządzanie projektem

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:

• jasny pogląd na strategiczne cele organizacji,

• upoważnienie do rozporządzania czasem i zasobami organizacji przy realizacji projektu.

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 :

• planowanie i sterowanie podstawowymi zasadami edukacji (Planning and Control Principles Education) zostało zaprojektowane, aby podnieść wiedzę Area Managers przy tworzeniu głównych zasad planowania zasobów,

• szkolenie w zakresie pojęciowym i zastosowań dostarcza zbiorczej i podręcznej wiedzy o BPCS dla Area Managers,

• zaawansowane szkolenia dostarczają Area Managers posiadających głęboką wiedzę na temat BPCS,

• Business Process Workshop dostarczają wiedzy na temat specyficznych zastosowań przedsięwzięć biznesowych.

• Diagnostyczne przeglądy działań dostarczają pełnej wiedzy na temat słabości, mocnych stron i wymagań procedur organizacji.

• Techniki strukturalne używane do zdefiniowania wymagań, projektowania konceptualnego i szczegółowego są samodokumentującymi się metodami do komunikacji wymagań pomiędzy technicznymi i nietechnicznymi członkami zespołu projektowego.

c) Efektywne zarządzanie projektem

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

• Planowanie projektu - składa się z ustalenia kosztorysu i harmonogramu wszystkich głównych faz projektu połączonych z nimi czynności i szczegółowych zadań.

• Organizacja projektu- składa się z rekrutacji wewnętrznego personelu oraz uzyskania profesjonalnej pomocy z zewnątrz w ten sposób aby obsadzić wszystkie role przy realizacji

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

• Kierowanie projektem- składa się z dostarczania wytycznych dla całego personelu zaangażowanego w projekt i zapewnienia sprzężenia zwrotnego żeby stwierdzić czy zadania zostały poprawnie zrozumiane. Opis czynności, opis technik strukturalnych oraz opis produktów gotowych do dostarczenia są punktem startowym dla kierowania czynnościami projektowymi.

• Kontrola projektu - składa się z regularnego monitorowania postępów względem planu oraz z podejmowania akcji korygujących w razie potrzeby. Raportowanie czynności i zdarzeń, stanu czynności ora stanu projektu ułatwiają kontrolę projektu.

8. Tradycyjne podejście

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

• brak jasnego zdefiniowania projektu

• brak zaangażowania naczelnego kierownictwa

• cele przedsięwzięcia nie są jasno określone i zrozumiane

• nowe cele systemu nie są powiązane z celami przedsięwzięcia

• brak pomiaru aktualnego postępu w stosunku do celów

• zasięg systemu nie jest jasno zdefiniowany i zrozumiały

• brak zdefiniowania odpowiedzialności za projekt

• Słabe zdefiniowanie wymagań przedsięwzięcia i użytkowników

• Nieadekwatne planowanie i sterowanie podstawowymi zasadami edukacji

• Słabe zrozumienie funkcji systemu

• Słabe zrozumienie odpowiedzialności końcowych użytkowników

• Nieefektywna komunikacja pomiędzy członkami zespołu projektowego

• Konflikt pomiędzy politykami organizacji (zasadami)

• Brak technik efektywnego zarządzania projektem

• Planowania projektu

• Organizowania projektu

• Kierowania projektem

• Kontroli projektu

• oczekiwania są nieodpowiednie i niewłaściwe

• nowy system nie spełnia faktycznych wymagań

• systemy nie są dostarczane z ustalonym wcześniej harmonogramem

• koszty projektu przekraczają budżet

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:

• czynności i zadania

• produkty gotowe

• role

• techniki strukturalne

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.

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ń:

• Czynności są identyfikowane przez liczbę trzysegmentową:

• pierwszy segment identyfikuje fazę i czynności z nią związane,

• drugi segment identyfikuje krok i przynależne mu czynności,

• trzeci segment identyfikuje czynność i może mieć długość 1 lub 2 cyfr.

• Zadania są identyfikowane przez liczbę pięciosegmentową:

• Pierwsze trzy segmenty identyfikują czynność do której należy zadanie

• Czwarty segment identyfikuje kod produktów BPCS do którego należy zadanie

• Piąty segment identyfikuje zadanie i może być 1 lub 2 cyfrowy

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:

• FS- Finish-Start (typ zwykły)- oznacza że czynność następująca nie może rozpocząć się dopóki czynność ją poprzedzająca nie zostanie zakończona.

• SS- Start-Start - oznacza że zależność następująca może rozpocząć się zaraz po rozpoczęciu jej poprzednika. Realizacja następnika nie jest jednak zależna od rozpoczęcia lub zrealizowania poprzednika.

• FF- Finish- Finish - oznacza że następnik nie może zakończyć się dopóki nie zakończy się poprzednik. Jednakże rozpoczęcie następnika nie jest zależne od rozpoczęcia lub zrealizowania poprzednika.

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:

• obszar górny - jest przeznaczony do czynności przygotowawczych

• obszar dolny - do czynności sprawdzających,

• reszta czynności jest umieszczona pośrodku

Kółka oznaczają czynności przygotowawcze

• harmonogramowanie spotkań i sesji

• potwierdzanie udziału całości wymaganego personelu

• planowanie udogodnień i zbieranie materiałów

Kwadraty oznaczają czynności

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

• oszacowanie kursu

• przegląd i zatwierdzenie produktu końcowego i planów projektu

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:

• standardowe produkty SSA włączając oprogramowanie BPCS /CS, dokumentację systemu i edukację,

• plany akcji włączając edukację i plany sesji prototypowania,

• dokumenty stworzone poprzez analizę, projektowania i sprawdzanie efektywności systemu,

• zainstalowane oprogramowanie BPCS/CS włączając wszystkie modyfikacje i udoskonalenia oprogramowania, wytycznych i procedur

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:

• rola kierownika projektu jest wykonywana przez jedna osobę

• rola kierownika projektu i Area Managera może być wykonywana przez jedna osobę szczególnie w przypadku małych przedsięwzięć projektowych.

• Rola komitetu sterującego i Area Managera są przyporządkowane grupom kierowników w organizacji,

• Rola konsultanta technicznego jest przyporządkowana całemu zewnętrznemu technicznemu personelowi (programistom, analitykom, liderom projektu, specjalistom od zapewnienia jakości i osobom sporządzającym projekt techniczny.

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:

• doprowadzenie fazy do pomyślnego zakończenia,

• zapewnienie, że produkt końcowy został stworzony zgodnie ze specyfikacją.

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 :

• alokacji ludzkich i finansowych zasobów na potzrzeby projektu

• podejmowaniu wszystkich strategicznych decyzji powiązanych z projektem

• Project Director Kierownik projektu jest również członkiem komitetu sterującego.

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 :

• wymagają standardowych zbiorów umiejętności ,

• używają standardowej terminologii i konwencji

• wytwarzają zapisy tego co zostało zrobione

• dostarczają możliwości do przeglądu jakości

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

Sześć kategorii technik strukturalnych:

• zarządzanie projektem - zawiera techniki planowania, kierowania i kontrolowania projektu,

• wywiad zawiera techniki przeprowadzania wywiadów z klientem i porządkowania informacji uzyskanych z tych wywiadów,

• zapewnienie jakości zawiera techniki sprawdzania i zatwierdzania specyficznych produktów końcowych BASIS,

• analiza jest wykorzystywana podczas fazy definicji projektu oraz podczas konceptualnego projektowania, modyfikacji i udoskonaleń systemu, ma to związek bardziej z wymaganiami przedsięwzięcia niż wymaganiami technicznymi,

• projektowanie jest wykorzystywane podczas prototypowania i szczegółowego projektowania czynności dotyczy ono wymagań technicznych a nie wymagań przedsięwzięcia,

• rozwój jest wykorzystywany podczas fazy rozwoju do modyfikacji i udoskonalania systemu.

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:

• Asekuracji systemu,

• Analizy ryzyka.

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ą:

• Polityki konfliktowe, które wymagają dalszego wyjaśnienia, łącznie z rozwiązaniem kwestii spornych;

• Polityki organizacyjne, procedury i kontrolę, które należy stworzyć;

• Wymagane modyfikacje i zmiany w standardowym oprogramowaniu BPCS Client/Server.

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

---