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:
Analiza
Spotkanie Wykonawcze
Wybór Zespołu Projektowego
Analiza i Plan Szkoleń
Szkolenia - Planowanie i Kontrola Zasad
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