Co to jest eksperymentalna przemysłowa eksploatacja sprzętu. Projektowanie zautomatyzowanych systemów

Zadaniem operacji próbnej jest testowanie algorytmów, programów i linków proces technologiczny przetwarzanie danych w warunkach rzeczywistych.

Próbna obsługa zadań odbywa się na podstawie rzeczywistych informacji, na tym etapie programista szkoli personel do pracy na komputerze przy użyciu określonego programu.

Eksploatacja pilotażowa podsystemów prowadzona jest w celu kompleksowego sprawdzenia wszystkich jego elementów, przygotowania bazy informacyjnej, debugowania procesu technologicznego zbierania i przetwarzania informacji, przeszkolenia personelu do pracy w warunkach funkcjonowania podsystemu. Eksploatacja próbna podsystemu powinna być prowadzona na podstawie pełnej ilości rzeczywistych informacji w ustalonym trybie pracy z niezbędnym powielaniem pracy. Uruchomienie podsystemu do eksploatacji komercyjnej odbywa się po uruchomieniu zadań kompleksu startowego tego podsystemu do eksploatacji próbnej.

Eksploatacja pilotażowa IS prowadzona jest w celu kompleksowego sprawdzenia funkcjonowania zadań systemu, sprawdzenia gotowości części wspierającej systemu do funkcjonowania, końcowego debugowania procesu technologicznego zbierania i przetwarzania informacji. Eksploatację próbną systemu należy przeprowadzić na podstawie wymaganej ilości informacji o aktywności obiektu w ustalonym trybie pracy. Po zakończeniu próbnej eksploatacji systemu sporządzany jest raport z wdrożenia.

Wdrożenie pilotażowe składa się z:

1. Przygotowanie wstępnych danych operacyjnych dla wszystkich kompleksów tego projektu

2. Wprowadzanie tych danych do komputera i przetaktowywanie oprogramowania

3. Analiza uzyskanych wyników w celu zidentyfikowania wszystkich błędów i nieścisłości.

Po pozytywnych wynikach eksploatacji próbnej system zostaje oddany do eksploatacji komercyjnej. W toku działalności komercyjnej przeprowadzana jest analiza funkcjonowania systemu, skuteczność wdrożonych decyzje projektowe w warunkach jego przemysłowej eksploatacji opracowanie zaleceń dotyczących dalszego rozwoju systemu i kształtowania standardowych rozwiązań.

Analiza funkcjonowania systemu przewiduje sprawdzenie:

— Funkcjonowanie środków technicznych

— Funkcjonowanie zadań i podsystemów w warunkach zautomatyzowanego przetwarzania

— Działanie personelu w warunkach funkcjonowania systemu

Wyniki analizy służą do oceny jakości systemu i jego faktycznej wydajność ekonomiczna. Prace nad analizą funkcjonowania systemu wykonuje deweloper na zlecenie nadzoru terenowego na podstawie umowy z klientem po pewnym okresie eksploatacji EIS. Nadzór autorski odbywa się kosztem środków przeznaczonych na stworzenie systemu. Program prac analitycznych jest opracowywany przez dewelopera i uzgadniany z klientem. Analiza funkcjonowania systemu rozpoczyna się po wydaniu zlecenia wykonania tej pracy. Zamówienie wskazuje warunki i przedmioty ankiety, a także wyznaczone przez przedstawiciela klienta zaangażowanego w tę pracę oraz osobę odpowiedzialną za terminowe i kompletne złożenie niezbędne materiały programista systemu. Zbieranie wszystkich danych, wypełnianie niezbędnych formularzy, rejestracja w czasopiśmie jest prowadzona przez przedstawiciela klienta i kontrolowana przez dewelopera. Zgromadzone dane są przekazywane w czasie określonym w programie przez przedstawicieli programistów do rozwoju. Wyniki przetwarzania danych dla każdego badanego elementu EIS są rejestrowane przez dewelopera przy udziale przedstawiciela klienta. Na podstawie wypełnionych protokołów deweloper, po wykonaniu wszystkich przewidzianych przez program prac, sporządza raport z analizy funkcjonowania EIS.

Dostarczenie klientowi raportu z analizy funkcjonowania systemu jest ostatnim etapem pracy dewelopera. W procesie analizy funkcjonowania zadań, podsystemów i działań personelu w kontekście wdrożenia EIS prowadzone są prace podobne do badania obiektu pod kątem parametrów poszczególnych funkcji podsystemów EIS, z uwzględnieniem uwzględnić kompleks zastosowanych środków technicznych oraz następujące czynniki:

- Terminowość otrzymania niezbędnych informacji kadrze zarządzającej;

— Zwiększenie wiarygodności informacji;

— Poprawa wydajności technicznej i ekonomicznej przedsiębiorstwa.

Jakość funkcjonowania poszczególnych podsystemów oceniana jest pod kątem wiarygodności i terminowości informacji, poprawiając jakość odpowiednich decyzje zarządcze. Na podstawie wyników analizy funkcjonowania systemu opracowywane są propozycje dalszego rozwoju EIS.

System zarządzania IT: trzy komponenty…

W kontekście tego zagadnienia, pod informatycznym systemem zarządzania rozumiemy zautomatyzowany system zarządzania działalnością działu IT, zbudowany w oparciu o specjalistyczne podejścia, metodyki, standardy i rozwiązania programowe dla branży IT. Podstawą koncepcyjną budowy takiego systemu jest „podejście usługowe”, czyli organizacja zarządzania usługą IT jako jednostką usługową oraz ukierunkowanie pracy całego personelu na świadczenie usług dla biznesu. Dlatego taki system zarządzania jest często określany jako „System Zarządzania Usługami IT”, a jego wdrożenie określane jest jako „Wdrożenie rozwiązania ITSM” lub „Projekt ITSM”.

System zarządzania IT nie ogranicza się oczywiście do narzędzi automatyzacji. Efektem końcowym projektu ITSM jest działający system zarządzania IT „pod klucz”. Jest to połączenie trzech elementów – „procesów”, „ludzi”, „narzędzi automatyzacji”. Gdy mówimy o wdrożeniu komercyjnym lub świadczeniu usług wdrożeniowych, wszystkie te elementy z reguły są zawarte w umowie z wykonawcą (integratorem systemów, firma doradcza) jako formalne przedmioty dostawy.

„Procesy” to tzw. dokumentacja procesowa, czyli cały szereg dokumentów organizacyjno-administracyjnych, które opisują i ustalają zasady pracy personelu działu IT, obszary odpowiedzialności oraz procedurę interakcji. Podstawa koncepcyjna nowoczesny system Zarządzanie IT (wraz ze wspomnianym już podejściem usługowym) to zarządzanie procesowe połączone z modelem branżowym opisanym w bibliotece ITIL. Konkretny projekt ITSM obejmuje jeden lub więcej powiązanych ze sobą procesów, dla których opracowywana jest dokumentacja procesu.

„Ludzie” to osoby w dziale IT, które uczestniczą w procesie wdrożenia, a następnie stają się użytkownikami systemu. Są nosicielami doświadczenia i znajomości konkretnych technologii i praktyk organizacji oraz wnoszą znaczący twórczy wkład w projektowanie systemu.

„Narzędzia automatyzacji” to zespół narzędzi technicznych i narzędzia programowe automatyzujące czynności w ramach procesów. Nie będziemy zwracać szczególnej uwagi na samo oprogramowanie, powiemy tylko, że na współczesnym rynku istnieje wiele specjalistycznych rozwiązań branżowych.

W przypadku Jet Infosystems flagowymi rozwiązaniami są (w kolejności alfabetycznej) linie produktów BMC Remedy ITSM Suite i HP Software Service Management Center. Tym samym wdrożenie rozwiązania ITSM jest celową zmianą trzech komponentów systemu zarządzania IT: dokumentacja normatywna, umiejętności personelu i narzędzia automatyzacji dla ograniczonej liczby czynności (procesów). Po podjęciu fundamentalnej decyzji o konieczności zmiany systemu zarządzania IT (uruchomienie projektu ITSM) rozpoczyna się etap planowania. Tutaj ustalane są kluczowe parametry projektu, identyfikowane są jego części składowe (zadania), określana jest wymagana ilość zasobów, wykonywana jest kolejność prac i ustalany jest budżet.

Na tym etapie organizacja podejmuje szereg ważnych decyzji. Przede wszystkim: co zmusza do realizacji projektu samodzielnie lub z udziałem konsultantów? Jakiego oprogramowania użyć? Aby odpowiedzieć na te pytania, istnieje wystarczająca liczba źródeł, które mogą pomóc organizacji, w tym badania, oceny i recenzje właścicieli takich systemów. Wspólne narzędzia do znajdowania najlepszych rozwiązań to proszenie o oferty techniczne i handlowe od wiodących integratorów, organizowanie prezentacji technicznych i demonstracji od różnych dostawców, uruchamianie projektów „pilotażowych” w celu porównania platform.

Przy ostrożnym podejściu organizacji do planowania pod kątem doboru narzędzi programowych i zespołu wykonawców, w większości przypadków technologiczny aspekt planowania projektu pozostaje za kulisami: co będzie podstawą tworzonego systemu, w jakim stopniu i jak ta podstawa zostanie sfinalizowana, aby uzyskać ostateczny wynik. Z reguły kwestia wyboru sposobu opracowania i realizacji na etapie przygotowania projektu nie jest podnoszona wprost, metoda ta jest niejako ukryta w szczegółowych planach projektu i pozostaje w gestii wykonawcy.

Naszym zdaniem niewystarczająco jasno zdefiniowany wybór metody rozwoju niesie za sobą wysokie ryzyko nieuniknionych odchyleń od planu (czyli takich, które wymagają znacznego przełożenia i doprecyzowania). części składowe projekt). Otwarta dyskusja i uzgodnienie oczekiwań klienta i wykonawcy co do sposobu realizacji pomoże ograniczyć wpływ takich ryzyk.

…i trzy warianty realizacji

Z całą różnorodnością platform i bogactwem funkcjonalność, prezentowanych na rynku specjalistycznych narzędzi programistycznych klasy „industrial”, organizacja ma do dyspozycji tylko trzy alternatywne sposoby wykorzystania ich do budowy systemu zarządzania. Nazwijmy je warunkowo: „Decyzja producenta”, ” najlepsze praktyki” i „Indywidualne rozwiązanie”.

„Rozwiązanie od producenta” - instalacja systemu automatyki „po wyjęciu z pudełka” i rozpoczęcie pracy zgodnie z referencyjnymi schematami technologicznymi producenta (z późniejszym dopracowaniem w procesie konserwacji). To najszybszy i najtańszy sposób na zorganizowanie pracy w nowy sposób.

„Dobrą praktyką” jest instalacja standardowego rozwiązania, stworzonego z góry przez firmę integratorską w oparciu o jej doświadczenie. Jest to najbardziej gwarantowany sposób na uzyskanie naprawdę działającego systemu.

"Rozwiązanie indywidualne" - opracowanie indywidualnego rozwiązania, począwszy od modelu procesu i regulacji procesu, a skończywszy na funkcjach ustawień interfejsu użytkownika. Ta metoda najlepiej pozwala uwzględnić życzenia pracowników i zmiany dostępne w organizacji.

Wybierając rozwiązanie od producenta, organizacja otrzymuje system automatyzacji ze wstępnie skonfigurowaną logiką biznesową i dokumentacją zawartą w standardowym pakiecie dostarczania licencji. Prace integratora nad stworzeniem takiego rozwiązania obejmują instalację i testowanie na kompleksie sprzętowym klienta, wprowadzenie danych referencyjnych o lokalizacji obiektów serwisowych, struktura organizacyjna, usługi, użytkownicy. Integruje się również z systemem pocztowym w celu wysyłania alertów. To zwykle wystarcza do rozpoczęcia szkolenia pracowników i obsługi systemu zarządzania.

„Dobra praktyka” (autorskie rozwiązanie firmy integratorskiej) zapewnia co najmniej wygodny, nie przeładowany interfejs użytkownika oraz zestaw zautomatyzowanych funkcji wystarczający do działania. Poza instalacją i wypełnianiem instrukcji, wdrożenie takiego rozwiązania wiąże się z pewną adaptacją dokumentacji procesowej i dopracowaniem systemu automatyki, głównie za pomocą narzędzi konfiguracyjnych, a nie programowania. Kluczowe warunki pomyślnego wdrożenia: prawidłowa ocena przydatności do konkretnej branży i klienta, obecność prostego i pięknego interfejsu, wysoka jakość dokumentacja i niezawodność eksploatacyjna.

Dwie pierwsze opcje („rozwiązanie producenta” i „najlepsza praktyka”) mają ze sobą wiele wspólnego. Są to gotowe rozwiązania, które nie są opracowywane w ramach projektu. Wdrażanie ich zasadniczo zaczyna się od wdrożenia i szkolenia. Plany wdrożeniowe takich rozwiązań są opracowywane z wyprzedzeniem, wielokrotnie testowane i nie zmieniają się z projektu na projekt. Jeśli organizacja zdecydowała się na jedną z tych opcji modernizacji systemu zarządzania, najważniejszymi problemami projektowymi jest wybór odpowiedniego dostawcy (platformy) i odpowiedniego integratora.

Wybierz "Rozwiązanie niestandardowe". Jak to zrobimy?

Najmniej przewidywalne, a przez to ciekawsze do rozważenia z punktu widzenia uczestników projektu, jest „Rozwiązanie indywidualne”, w ramach którego następuje przede wszystkim projektowanie i rozwój systemu specyficznego dla konkretnej organizacji. Projekty realizacji poszczególnych rozwiązań mogą się znacznie różnić pod względem kosztów i terminów. Z naszego doświadczenia najważniejszy jest tu sposób organizacji projektu.

Jak podstawy metodologiczne projektowanie i wdrażanie indywidualnych rozwiązań, ogólnie, standardów zarządzania projektami, standardów i podstawowych przepisy prawne zarządzanie cyklem życia oprogramowania, a także metodologię projektowania oprogramowania znanych producentów (Microsoft, Oracle, HP, BMC itp.). Na ich podstawie firma integratorska tworzy własny profil standardów i metod regulujących procesy projektowania, rozwoju, eksploatacji i rozwoju System informacyjny. Wszystkie te standardy i metodologie są dostosowywane i skonkretyzowane w odniesieniu do określonych klas projektów, w naszym przypadku projektów ITSM.

Ryż. 1. Mapa produktu

Rezultatem jest zestaw konkretnych wytyczne, wymagania, właściwości i wskaźniki jakości, które charakteryzują sposób organizacji rozwoju i wdrażania systemu. Kolejna część cech indywidualnego rozwiązania – głównie funkcjonalna i techniczna – jest kreatywnie określana przez klienta i wykonawcę już w procesie rozwoju.

Dzięki temu nawet dla indywidualnego rozwiązania na etapie planowania projektu znaczna część decyzji projektowych jest z góry ustalona i znana wykonawcy. Dlatego zasadne jest zrównanie dyskusji o sposobie rozwoju z takimi kwestiami przygotowania projektu, jak wybór platformy (dostawcy) i wybór architektury.

W jakiej kolejności będą uzyskiwane wyniki projektu? Jak będą tworzone i zbierane komentarze klientów? W jakiej kolejności iw jakim stopniu komentarze będą przyjmowane i eliminowane? Te i inne pytania charakteryzujące sposób organizacji projektu stosowany przez wykonawcę można postawić:
na etapie planowania, w tym w celu dokładniejszego porównania konkurencyjnych ofert i wybrania najlepszej.

Główne pytanie metody rozwoju: jak otrzymujemy produkty projektu? Aby samemu to zrozumieć, opowiedzieć o tym klientowi, a co najtrudniejsze, zrealizować nasze plany, korzystamy z map produktów projektowych. Mapa produktu to diagram wyników pośrednich i końcowych prac projektowych, który określa, co i w jakiej kolejności zostanie wyprodukowane podczas projektu (patrz). Podstawą metodologiczną budowania mapy produktów jest metoda planowania opartego na produktach firmy Prince2, która służy do opracowania struktury podziału pracy.

Nasze mapy są „rysowane” według etapów projektu, na których nanoszone są produkty projektu w postaci prostokątów. Prostokąty są połączone linkami, linki określają, na podstawie których produktów powstają kolejne produkty. W ten sposób mapa produktu określa technologię wytwarzania systemu sterowania.

Wszystkie produkty można podzielić na dwie grupy. Pierwsza grupa to „zewnętrzne”, które dostarczane są do klienta. Drugi to „wewnętrzny”, który z reguły jest niezbędny zespołowi projektowemu jako komponent technologiczny, aby uzyskać jeden z produktów „zewnętrznych”.
Stosujemy inną klasyfikację produktów: „obowiązkowe” i „opcjonalne”. Produkty „obowiązkowe” to produkty, których rozwój jest konieczny z technologicznego punktu widzenia (bez nich nie można uzyskać końcowego rezultatu projektu ITSM). „Opcjonalne” odnosi się do produktów, z których można zrezygnować. Produkty „opcjonalne” umieszczane są w karcie produktu z reguły na życzenie klienta.

Skład, kolejność i wzajemne powiązania produktów składających się na główną wartość mapy są określane heurystycznie, trudno wyobrazić sobie uniwersalny algorytm kompilacji takiej mapy. To efekt wieloletniego doświadczenia wdrożeniowego, ogromnej ilości błędów, fundamentalnych sporów ideologicznych, nagłych odkryć, prób, które zdały próbę czasu i realnych projektów.

Na podstawie mapy produktu możesz wyraźnie pokazać główne różnice i cechy rozważanej metody rozwoju. Większość realizowanych przez nas projektów można przypisać jednemu z dwóch sposobów organizacji pracy. Nazwijmy je umownie „klasycznymi” i „iteracyjnymi” i rozważmy każdy z nich osobno.

Każdy przykład produktu w artykule jest opisany w następujący sposób:

• Forma;
• Wizyta, umówione spotkanie;
• Zawartość;
• Opcje, zalecenia.

„Klasyczny” sposób wdrożenia systemu zarządzania IT

Istotą „klasycznej” metody wdrożenia jest stopniowy rozwój systemu, począwszy od badań Tematyka a kończąc na wdrożeniu systemu „pod klucz” i dalszym wsparciu. Wyróżniamy (i mapujemy) następujące etapy projektu:

• badanie;
• Projekt;
• Rozwój;
• Zastosowanie;
• Eksploatacja pilotażowo-przemysłowa;
• Uruchomienie;
• Wsparcie techniczne i konserwacja.

W przypadku „klasycznej” metody realizacji etapy są bardzo ważne, ponieważ wyniki uzyskane na końcu etapu (produkty projektu) stanowią podstawę kolejnego etapu, a ich weryfikacja jest prawie niemożliwa bez wprowadzania zmian w projekt. Rozważ główne produkty projektu na każdym etapie.

Etap 1: Badanie

Cele etapu ankiety są dwa: uzyskanie wyobrażenia o obecnej praktyce w obszarze tematycznym oraz wyjaśnienie opisu problemu. Głównym rezultatem etapu jest raport z badania. Jeśli podążasz za mapą, pierwszym produktem etapu jest „Struktura przedmiotu zarządzania” (inna nazwa to „Model ankiety”). Nie jest wydawany klientowi, jest produktem „wewnętrznym”. W nim, zgodnie z tym samym schematem „ludzie - procesy - narzędzia automatyzacji”, ustala się: co należy zbadać w ramach ankiety, jakie dokumenty otrzymać i przestudiować, z jakimi osobami przeprowadzić wywiady, z jakich narzędzi automatyzacji klient do rozważenia.

Raport z badania

Forma

Dokument tekstowy (głównie), prezentacja.

Zamiar

Raport z ankiety jest najciekawszym i najciekawszym do przeczytania dokumentem projektowym. Na początku projektu raport jest przydatny do stworzenia atmosfery wzajemnego zrozumienia we wspólnym zespole projektowym „Klient – ​​Wykonawca”: konsultanci wykazują zrozumienie specyfiki i priorytetów organizacji, a przedstawiciele klienta akceptują i wyrażają zgodę na wykorzystanie terminy i narzędzia projektów ITSM, na przykład „struktura procesu ról” i poziom dojrzałości.

Drugie życie „Raportu” rozpoczyna się pod koniec projektu, kiedy wymagane jest zademonstrowanie efektu wprowadzenia nowego systemu (było – było). W przyszłości, po uruchomieniu systemu sterowania, staje się on zbędny i praktycznie nie jest używany.

Na podstawie którego jest rozwijany

Konsultanci przygotowują raport na podstawie notatek sporządzonych podczas rozmowy, a także na podstawie zebranych dokumentów organizacji: regulaminów, instrukcji itp. Dokładność i jakość są proporcjonalne do kwalifikacji konsultantów i ich liczby na rozmowę (jeden konsultant jest zły). Jeśli ankieta została przeprowadzona w trakcie ankiety (co nie zdarza się za każdym razem), wyniki są przetwarzane i uwzględniane w raporcie w formie zagregowanej.

Typowy raport jest warunkowo podzielony na trzy główne bloki: informacje ogólne, opis obecnej sytuacji, wnioski.

Informacje ogólne to określone cele ankiety, granice ankiety (organizacyjne i funkcjonalne), lista wykorzystanych dokumentów oraz ankietowani. Zawiera również opis metodologii badania, w tym metody zbierania informacji, metody grupowania i uogólniania, metody i kryteria oceny.

Opis aktualnej sytuacji jest ustrukturyzowaną prezentacją obecnej praktyki „tak jak jest”, czasami z wykorzystaniem diagramów graficznych i rysunków. Dla wszystkich badanych obszarów działalności organizacji stosuje się jedną strukturę opisu. Na przykład tak:

• Struktura organizacyjna i rolowa;
• Działania procesowe;
• Obsługa dokumentacji;
• Wsparcie informacyjne;
• Środki automatyzacji.

Często sekcja zawiera wymagania zarządcze i sugestie ulepszeń zebrane podczas ankiety, jeśli to możliwe, bez zmiany sformułowania.

Sekcja „Wnioski” zawiera wyniki analizy obecnej sytuacji. Niemal zawsze są to wyniki oceny stopnia dojrzałości procesów, a także zidentyfikowanych „wąskich gardeł” i związanych z nimi zagrożeń.

Po sekcji „Wnioski” wydaje się logiczne, że mamy kilka rekomendacji, jednak w kontekście trwającego projektu ITSM można to zaoszczędzić: projekt został uruchomiony, budżet został zatwierdzony, wymagania zostały sformułowane – to wszystko czas zacząć projektować.

Zespół projektowy klienta jest często zainteresowany treścią wywiadów, które konsultanci przeprowadzają z kierownictwem wyższego szczebla IT i przedstawicielami biznesu. Aby zaspokoić takie zainteresowanie, zaleca się wcześniejsze uzgodnienie z kierownictwem publikacji tematów poruszanych w raporcie lub obecność lidera zespołu projektowego klienta na rozmowę kwalifikacyjną.

Na jej podstawie opracowywany jest produkt pośredni „Plan ankiety”, a od niego wywodzi się produkt „zewnętrzny” „Harmonogram ankiety”. Produkt „Harmonogram kontroli” uważa się za gotowy, gdy zostanie uzgodniony z klientem. W tym momencie mamy jasne wyobrażenie o tym, jak odbędzie się badanie. Kontynuując plan ankiety, „wewnętrzny” produkt to zestaw materiałów, które składają się na wyniki ankiety — wszystko, co jest zbierane w ramach ankiety. Następnie tworzony jest „Raport z ankiety” – główny wynik etapu. Można z niego wyprowadzić „opcjonalny” produkt „Prezentacja wyników ankiety”.

Etap 2: Projekt

Celem fazy projektowej jest zaproponowanie i uzgodnienie z klientem rozwiązań organizacyjnych i technicznych, które będą stanowić podstawę tworzonego systemu zarządzania IT. Głównymi rezultatami etapu są „Model systemu zarządzania IT” oraz „Opisy (regulacje) procesów” szczegółowo go uszczegóławiające.

Model procesu

Forma

Dokument tekstowy, prezentacja (w większości).

Zamiar

Model procesu to zbiór kluczowych cech tworzonego systemu sterowania. Są to najbardziej kosztowne elementy projektu przyszłego systemu, które należy podjąć na wczesnym etapie projektu, aby uniknąć znacznych przeróbek. Model procesu jest zwarty, zawiera tylko to, co ważne i jest wygodny do dyskusji i uzgodnienia.

Na podstawie którego jest rozwijany

Początkowe ograniczenia w opracowaniu modelu procesu to definicja projektu w organizacji i odpowiednie zapisy umowy z wykonawcą. Z reguły skład procesów - podsystemów przyszłego systemu sterowania - jest z góry określony. Cele projektu są znane i zatwierdzone, np. „Wdrożenie w Dziale podejścia procesowego IT skoncentrowanego na potrzebach biznesowych. Wdrożenie elementów światowych „najlepszych praktyk” zarządzania IT”.

Źródłami zewnętrznymi wykorzystanymi do opracowania modelu są przyjęte standardy, „najlepsze praktyki” oraz poprzednie doświadczenie członkowie drużyny.

Głównym źródłem rozwoju projektu jest raport z badania, a raczej opis obecnej praktyki i jej wąskich gardeł. Nowy model powinien zachować dobrze funkcjonujące praktyki zarządzania i eliminować słabości.

W opisie modelu procesu warto oprzeć się na szeroko stosowanym podziale systemu na trzy komponenty – „procesy”, „ludzie”, „narzędzia automatyzacji”.

Dla każdego procesu z reguły model wychwytuje następujące elementy decyzyjne:

• Warunki i definicje;
• Profil obowiązujących standardów i praktyk zarządzania;
• Docelowy poziom dojrzałości i jego charakterystyka;
• Cele procesu;
• Wejścia i wyjścia (rezultaty) procesu;
• Obiekty informacyjne;
• Rodzaje czynności, ogólny schemat procesu.

Zestaw innych kluczowych cech (innymi słowy „polityk”) zawartych w modelu jest specyficzny dla każdego procesu. W przypadku zarządzania incydentami może to być liczba linii wsparcia, organizacja help desku (scentralizowana lub rozproszona, rozwiązywanie lub logowanie), obsługiwane metody kontaktu z help deskiem.

W ramach struktury ról systemu („ludzie”) model określa skład i odpowiedzialność ról za rodzaje działań procesów. Dla każdej roli należy ocenić możliwość powołania lub zatrudnienia personelu. Jeśli konieczna jest zmiana struktury organizacyjnej, należy to wyraźnie zaznaczyć.
Jeśli chodzi o narzędzia automatyzacji, jeśli do tej pory nie zostały jeszcze wybrane i zakupione, to model procesu zawiera listę planowanych do użycia narzędzi programowych oraz określa potrzebę i sposoby integracji z powiązanymi systemami (źródła danych o pracownikach, inwentaryzacja systemów pocztowych, programów pocztowych itp. .d.).

Aby model procesu nie stał się materiałem marketingowym lub, powiedzmy, raportem własnym zespołu projektowego (na którym chcielibyśmy zaoszczędzić pieniądze), zaleca się uwzględnienie tych elementów systemu, dla których omówiono alternatywne opcje projektowe.

Model jest centralnym produktem sceny. Opracowanie i zatwierdzenie modelu odbywa się w kilku iteracjach przy zaangażowaniu najszerszej grupy roboczej klienta. Błędy popełnione podczas opracowywania modelu z pewnością odczują się na kolejnych etapach projektu. Cena emisji: przynajmniej znaczne przetworzenie już uzyskanych wyników i niezadowolenie klientów. Na podstawie uzgodnionego modelu opracowywane są „Schematy procesów” jako etap pośredni w opracowywaniu „Opisów (regulacji) procesów”.

Regulacja procesu

Forma

Dokument tekstowy zawierający diagramy graficzne.

Zamiar

Po zapoznaniu się z regulaminem uczestnicy procesu i zainteresowane strony (np. audytorzy) powinni zorientować się w następujących kwestiach: w jakim celu i jakie czynności są wykonywane w procesie (bez szczegółowego opisu w jaki sposób) i kto jest odpowiedzialny za Co.

Na podstawie którego jest rozwijany

Półproduktem do opracowania przepisów jest model procesowy. Uzgodnione wcześniej czynności dzielą się na procedury, ustala się uczestników procedur i osoby odpowiedzialne. Opisano same procedury, warunkowe i bezwarunkowe przejścia między nimi, bardziej szczegółowo - w punktach przekazania kontroli.

Rozporządzenie jest logicznie powiązanym formalnym opisem działań procesu ze wskazaniem odpowiedzialnych. Oto przybliżona struktura rozporządzenia (weźmy zarządzanie incydentami):

• Warunki i definicje;
• Postanowienia ogólne:
  • Cele i zadania procesu;
  • Korzyści z procesu;
  • Zakres i granice procesu;
  • Dane wejściowe do procesu zarządzania incydentami;
  • Dane wyjściowe z procesu zarządzania incydentami;
  • Ogólny schemat i opis procesu;
  • Narzędzia procesowe;
• Role i obowiązki uczestników procesu:
  • role funkcjonalne;
  • Matryca Odpowiedzialności;
• Regulacja procesu:
  • Odbiór i rejestracja;
  • Klasyfikacja i wsparcie podstawowe;
  • Wizyta, umówione spotkanie;
  • Pozwolenie, wykonanie;
  • zamknięcie;
  • Własność;
• Metryki procesu:
• Komponenty i raporty dostarczane przez proces;
• Załącznik A – Zasady klasyfikacji;
• Załącznik B – Zasady ustalania priorytetów;
• Załącznik B – Zasady eskalacji.

Aby regulamin był używany zgodnie z jego przeznaczeniem, czyli był czytany do końca, zaleca się umieszczenie we wnioskach lub innych dokumentach (specyfikacjach i instrukcjach) wszelkich rozpraszających uwagi szczegółów naruszających logicznie powiązany opis.

Etap 3: Rozwój

Celem etapu rozwoju jest stworzenie narzędzi automatyzacji oraz opracowanie dokumentacji procesowej.

Na podstawie „Opisów (regulacji) procesów” opracowywane są „Specyfikacje procesów”. Dla każdego procesu zarządzania w systemie opracowywane są trzy specyfikacje: „Specyfikacja przepływu pracy”, „Specyfikacja metryk” i „Specyfikacja integracji”. Na ich podstawie tworzone są „scenariusze testowania SA”.

Specyfikacja procesu

Forma

Dokument tekstowy.

Zamiar

Specyfikacja procesu uszczegóławia postanowienia rozporządzenia. Jeżeli rozporządzenie określa, co iw jakiej kolejności jest wykonywane w procesie, to specyfikacja odpowiada na pytanie: jak dokładnie iz jakimi wynikami wykonywane są procedury. Jako dokument projektowy, specyfikacja zawiera podstawowe wymagania funkcjonalne do opracowania zautomatyzowanego systemu. W przyszłości służy jako podstawa do zestawiania scenariuszy testowych i instrukcji pracy dla uczestników procesu.

Na podstawie którego jest rozwijany

Specyfikacja opracowywana jest na podstawie rozporządzenia i uszczegóławia jego procedury z uwzględnieniem ograniczeń i możliwości wybranych narzędzi automatyzacji.

W specyfikacji procedury procesowe podzielone są na sekwencję kroków - elementarnych operacji uczestników procesu (użytkowników systemu). Struktura opisu procedury jest w przybliżeniu następująca:

• Opis procedury:
  • Numer (identyfikator) procedury;
  • Nazwa procedury;
  • Opis procedury (z regulaminu);
  • Odpowiedzialny wykonawca (rola);
• Wejście do procedury (zdarzenie uruchamiające procedurę);
• Operacje.

Dla każdej operacji określ:

• numer operacji;
• nazwa operacji;
• Podjęte działania;
• Wynik operacji.

Po wprowadzeniu systemu sterowania do eksploatacji, w celu obniżenia kosztów utrzymania, zaleca się wprowadzenie zmian w przepisach i specyfikacji, a następnie „wycięcie” instrukcji i scenariuszy ze specyfikacji.

Równoległy Praca w toku do tworzenia narzędzi automatyzacji: tworzony jest produkt pośredni „Podstawa CA (systemy automatyzacji)”, następnie „Stojak roboczy SA” - poprzez ustawienie podstawy zgodnie ze specyfikacją. Produkt „zewnętrzny” „SA Experimental Bench” jest uzyskiwany w oparciu o zestaw „SA Workbench” i „SA Testing Scenarios”: dzięki wysiłkom zespołu testerów i inżynierów system automatyki zostaje doprowadzony do gotowości do demonstracji do klienta, szkolenie i eksploatacja próbna.

W oparciu o specyfikacje i „Stanowisko Eksperymentalne SA” opracowywany jest zestaw produktów „Instrukcje użytkownika SA”. Powstały „zewnętrzny” produkt sceny to „Demonstracja CA” dla zespołu projektowego klienta.
Opcjonalnymi produktami „zewnętrznymi” na tym etapie mogą być: „Warunki odniesienia” (w oparciu o specyfikacje), „Metoda testowa” (w oparciu o „Scenariusze testów”), „Opis karty wyników” (w oparciu o zestaw „Specyfikacji wskaźników” ).

Etap 4: Wdrożenie

Celem fazy wdrożenia jest przygotowanie obiektu kontrolnego do eksperymentu lub eksperymentu użytek przemysłowy systemy automatyki.

Plan działania pilota (pilota)

Forma

Dokument tekstowy, plan w MS Project.

Zamiar

Dokument służy jako narzędzie planowania i organizowania wspólnych działań uczestników, aby zapewnić osiągnięcie celów operacji próbnej w określonym czasie (zwykle od dwóch tygodni do półtora miesiąca).

Na podstawie którego jest rozwijany

Plan zawiera dwa główne rozdziały: zasady prowadzenia eksploatacji próbnej oraz sam plan.

Procedura obsługi pilota odpowiada na następujące pytania:

• Jakie cele mają zostać osiągnięte?
• Jakie są ramy czasowe dla operacji próbnej?
• Jakie działy i pracownicy są zaangażowani?
• Jakie role w procesach są im przypisane?
• Jaki rodzaj materiały dydaktyczne dostępne dla członków i gdzie są publikowane?
• Z kim i na jakie pytania się kontaktować, w jakich warunkach i jak?
• W jakim trybie wykorzystywane są „stare” systemy i technologie?
• Czy podczas próbnej eksploatacji zostaną wprowadzone zmiany w systemie?

Plan pracy próbnej zawiera listę etapów i zadań ze wskazaniem odpowiedzialnych, czasu trwania i harmonogramu każdego zdarzenia. Przykładami takich działań mogą być „uruchamianie i testowanie odbioru zgłoszeń użytkowników za pomocą interfejsu WWW”, „przeprowadzenie audytu konfiguracji”.

Wyniki tego etapu są w większości „zewnętrzne” – widoczne dla klienta. Jeśli podążasz za zwykłą strukturą „ludzi”, „procesów” i „narzędzi automatyzacji”, są to następujące produkty: „Przeszkolony personel”, „ Wydarzenia organizacyjne” (w celu uruchomienia i uruchomienia systemu zarządzania IT) oraz „Narzędzia automatyzacji” wdrożone u klienta. Aby uzyskać te wyniki, na początku operacji pilotażowej opracowywany jest i uzgadniany z klientem „Plan szkoleniowy”, „Plan wdrożenia SA”, „Plan wydawania zamówień i zamówień”. Równolegle w interesie kolejnego etapu opracowywany jest „zewnętrzny” produkt „Pilotażowy Plan Operacyjny”.

Etap 5: Operacja pilota

Celem fazy pilotażowej jest przetestowanie systemu zarządzania IT w: warunki pracy w siedzibie klienta. Na podstawie Planu Eksploatacji Pilota na etapie tworzony jest produkt „wewnętrzny” „Wyniki Eksploatacji Pilota”, na podstawie którego zostaną opracowane produkty „Zewnętrzne” „Sprawozdanie z Eksploatacji Pilota” oraz „Protokół Uwag i Usprawnień” przygotowany. „Opcjonalnym zewnętrznym” produktem sceny może być „Prezentacja wyników operacji pilotażowych”.

Etap 6: Uruchomienie

Centralnym wydarzeniem fazy uruchomienia jest wprowadzenie informatycznego systemu zarządzania do trybu produkcyjnego. W tym celu konieczne jest wyeliminowanie uwag formułowanych na etapie działania pilotażowego. Na podstawie „Stoiska Eksperymentalnego SA” oraz „Protokołu uwag i usprawnień” opracowywany jest produkt „zewnętrzny” „Stanowisko Przemysłowe SA”. Powstały etap i projekt jako całość to „zewnętrzny” produkt „Prezentacja wyników projektu”.

Po zakończeniu projektu: Wsparcie techniczne i konserwacja

Z punktu widzenia planowania i organizacji pracy wsparcie techniczne i utrzymanie informatycznego systemu zarządzania ma charakter procesowy, a nie projektowy i jest budowane według innych zasad. Dlatego na naszej mapie produkty projektu związane z działaniami wsparcia i utrzymania nie są odzwierciedlone.
W ten sposób za pomocą mapy produktów zbadaliśmy technologię realizacji projektu opracowania i wdrożenia „indywidualnego rozwiązania” dla systemu zarządzania IT według schematu „klasycznego”. Należy zauważyć, że dla uproszczenia prezentacji uproszczono skład produktów projektu. W rzeczywistych mapach, z których korzystamy, dla jednego produktu projektu można zapewnić kilka produktów pośrednich. Np. „Produkt” staje się najpierw „Wzorem Produktu”, potem, po akceptacji wewnętrznej, „Wzorem Produktu”, a dopiero po uzgodnieniu z Klientem – rzeczywistym „Produktem”. Innymi słowy, mapa może wyświetlać nie tylko produkty i ich relacje, ale także cykle życia poszczególne produkty.

Po skompilowaniu takiej mapy produktu możesz przystąpić do sporządzenia planu projektu, na przykład za pomocą Projekt Microsoft. Produkty projektu w planie zostaną przedstawione w postaci kamieni milowych, które należy uszczegółowić Praca projektowa. Wymaga to sformułowania każdego zestawu przychodzących linków produktowych jako zadań do wytworzenia produktu na podstawie poprzednich. Szacując czas trwania powstałych zadań projektowych, otrzymujemy podstawowy plan projektu.

„Iteracyjny” sposób wdrożenia systemu zarządzania IT

„Klasyczna” metoda realizacji jest najpopularniejsza na rynku usługi doradcze, jest bardzo popularny i sprawdzony w czasie. Ma jednak jedną wadę, a właściwie cechę, która w dzisiejszych warunkach nabiera coraz większego znaczenia zarówno dla klienta, jak i wykonawcy. Chodzi o czas trwania. Projekty wdrażania systemów sterowania w sposób „klasyczny” rzadko są realizowane w czasie krótszym niż trzy miesiące. Wręcz przeciwnie, nierzadko zdarza się, że takie projekty trwają dłużej niż rok. W tym czasie mogą ulec zmianie warunki zewnętrzne, w jakich działa firma,
jak również plany, priorytety biznesowe. Przeobraża się pomysł menedżerów usług IT o tym, jak powinien działać system zarządzania. Wszystkie te czynniki, a także błędy planistyczne kumulują się i prowadzą do tego, że w środkowej i końcowej fazie projektu pojawia się zwiększona chęć zmniejszenia zaległości ze szkodą dla jakości lub ilości produktów projektu.

„Iteracyjny” sposób implementacji znacznie zmniejsza wpływ tych zagrożeń. Ma to na celu przede wszystkim możliwość korygowania postępu wdrożenia, przy założeniu rewizji przyszłych planów w każdej iteracji.

Jest oczywiste, że wynik „projektu iteracyjnego” na formalnych przedmiotach dostawy nie powinien różnić się od „projektu klasycznego”. Przynieśmy ogólny schemat formalny zestaw przedmiotów dostawy:

• Ludzie:
  • Uczestnicy ankiety;
  • Uczestnicy projektu systemu sterowania;
  • Przeszkolony;
  • Uczestnicy operacji pilotażowej;
• Procesy (dokumenty):
  • Raport z badania;
  • Model procesu;
  • Schematy, opisy (regulacje) procesów;
  • Specyfikacje;
  • Instrukcje dla administratora systemu, dokumentacja systemu automatyki;
• Narzędzia automatyzacji:
  • Podstawowe stanowisko systemu automatyki;
  • Stanowisko pracy systemu automatyki;
  • Doświadczone stoisko systemu automatyki;
  • Stanowisko przemysłowe systemu automatyki.

  Wszystkie te produkty muszą być uzyskane w ramach „projektu iteracyjnego”, tak jak są uzyskiwane w ramach „projektu klasycznego”.

  Iteracja implikuje powtórzenie. W naszym przypadku powtórzone zostaną następujące grupy zadań:

• Badania (temat);
• Ustalenie granic wyniku iteracji (wydania);
• Rozwój wydania, który obejmuje:
  • Rozwój;
  • Testowanie wyniku przez dewelopera;
  • Testowanie wyniku przez kierownika zadań;
  • Akceptacja wydania przez kierownika zadania;
• Akceptacja wydania przez klienta.

Oczywiście „akceptacja wydania” zarówno w cyklu minidevelopmentu, jak i w głównym cyklu iteracyjnym prowadzi albo do przejścia do nowej iteracji, albo do powtórzenia (w pewnym stopniu) obecnej w celu wyeliminowania braków.

Opisaliśmy więc, co należy uzyskać (produkty projektu) i jak to zrobimy (jeden cykl iteracji). Pozostaje pokazać, w ilu iteracjach produkt zostanie opracowany i szczegółowo opisać pracę w ramach każdej iteracji. Uważamy, że optymalna liczba iteracji wyniesie trzy, czwarta i kolejne iteracje mogą być wykonane w ciągu pomoc techniczna oraz utrzymanie informatycznego systemu zarządzania. Podobnie jak w przypadku „klasycznej” metody rozwoju, rozważmy logikę uzyskiwania głównych produktów projektu w kontekście trzech iteracji projektu.

Iteracja 1: Opracowanie wersji pilotażowej (1.0)

Grupa zadań projektowych „Badania” w ramach pierwszej iteracji obejmuje duży nakład pracy, która w „klasycznym” opracowaniu wykonywana jest na etapach badań i projektowania:

• badanie;
• Rozwój modelu.
  Następnie wykonywana jest grupa zadań projektowych „Określenie granic wydania”, która będzie obejmować następujące prace:
• Definiowanie granic wydania pod względem przepływu pracy, metryk i integracji;
• Uzgodnienie granic uwalniania.

Zadania wchodzące w skład grupy „Rozwój” realizowane są w celu uzyskania prototypu systemu, gotowego do demonstracji u klienta.

Pierwszą iterację rozwoju kończy grupa zadań projektowych „Odbiór”, która obejmie następujące prace:

• Demonstracja wydania grupie roboczej klienta;

W ten sposób, pod z góry ustalonymi warunkami i ograniczeniami, otrzymujemy rodzaj kompletnego, działającego rozwiązania (zwolnienie pilotażowe), w skład którego wchodzą następujące produkty:

• personel klienta zaangażowany w ankietę;
• Personel klienta zaangażowany w projektowanie systemu sterowania;
• Raport z badania;
• Model;
• Schematy procesów;
• Zestaw specyfikacji;
• Uzgodnione granice wydania 1.0;
• Stanowisko pracy SA.

Iteracja 2: Rozwój wersji beta (2.0)

Grupa zadań projektowych „Badania” w ramach drugiej iteracji ma znacznie mniejszą skalę niż w przypadku wydania pilotażowego i obejmuje jedno zadanie:

• Test wydania Grupa robocza klient.

Grupa zadań projektowych „Określenie granic wydania” składa się z następujących prac:

• Uzgodnienie granic uwalniania.

• Podjęcie decyzji o udoskonaleniu wydania lub przejściu do następnej iteracji.

Wynikowymi produktami iteracji 2 są:

• Uzgodnione granice wersji 2.0;
• Doświadczone stoisko SA;
• Opisy (regulacje) procesów;
• Instrukcja obsługi systemu automatyki;
• Metodyka programu i testów;
• Personel klienta zaangażowany w testowanie narzędzi automatyzacji.

Iteracja 3: Rozwój wersji produkcyjnej (3.0)

Aby uzyskać wersję przemysłową, grupa zadań projektowych „Badania” ma na celu poszerzenie kręgu uczestników w celu głębszego i lepszego testowania rozwiązania w warunkach jak najbardziej zbliżonych do rzeczywistych.

Raport z operacji pilota (pilot)

Forma

Dokument tekstowy.

Zamiar

Dokument rejestruje wyniki oceny pracy uczestników operacji pilotażowej pod kątem celów tego etapu projektu, a także przedstawia aktualny stan systemu sterowania, jego gotowość do użytku przemysłowego oraz obszary do doskonalenia.

Na podstawie którego jest rozwijany

Raport służy do porównania planowane wskaźniki przy czym faktycznie w opracowaniu wykorzystywane są dwie grupy źródeł informacji. Plan działania pilotażu i materiały metodyczne dla uczestników procesu (regulaminy, instrukcje itp.) są traktowane jako podstawa oceny, a dane rzeczywiste są tworzone przez uczestników działania pilotażu w trakcie pracy i analizowane przez konsultantów podczas audytu systemu .

Typowy raport zawiera trzy sekcje: informacje ogólne, ocena realizacji pilotażowego planu działania, ocena działań w ramach zreorganizowanych procesów.

Informacje ogólne to przede wszystkim źródła danych i kryteria oceny wykorzystywane do wygenerowania raportu. Pożądane jest, aby wybrane kryteria obejmowały zarówno kontrolę procesów i wykonanie procedur procesowych, jak i wyniki realizacji planu ruchu próbnego.

Dla każdej pozycji planu przeprowadzana jest ocena realizacji pilotażowego planu operacyjnego. W przypadku całkowitej lub częściowej niezgodności wskazane są przyczyny. Sekcja może zawierać kilka ważnych cech ilościowych i jakościowych wyników, na przykład liczbę błędów i komentarzy.

Ocena działań w ramach procesów odbywa się według opracowanych kryteriów z utworzeniem uogólnionej oceny powodzenia uruchomienia każdego procesu i systemu zarządzania jako całości. W takim przypadku można wykorzystać metryki i narzędzia raportowe, które są częścią wdrożonego systemu. Przydatnym elementem tej części raportu jest opis zidentyfikowanych uchybień, związanych z nimi zagrożeń oraz rekomendacje dotyczące ograniczania ich wpływu.

Przy wdrażaniu złożonego, bogatego funkcjonalnie systemu na dużym obszarze (na przykład, gdy operacja nie jest eksperymentalna, ale pilotażowo-przemysłowa), przydatne jest sporządzenie krótkiego raportu pośredniego po upływie jednego do dwóch tygodni od startu.

W skład grupy wejdą:

• Szkolenie użytkowników systemu;
• Eksploatacja pilotażowo-przemysłowa.

• Tworzenie listy ulepszeń;
• Ustalenie sposobu wdrażania usprawnień;
• Uzgodnienie granic uwalniania.

Grupa zadań projektowych „Rozwój” w swojej treści również powtarza poprzednią iterację. Iterację uzupełnia grupa zadań projektowych „Odbiór”, która obejmie następujące prace:

• Opracowanie programu i metod testowania;
• Akceptacja wydania przez grupę roboczą Klienta;
• Podjęcie decyzji o udoskonaleniu wydania lub przejściu do następnej iteracji.

Tak więc iloczynami iteracji 3 są:

• Podręcznik administratora;
• Opis ustawień systemu automatyki;
• Uzgodnione granice wersji 3.0;
• Stoisko przemysłowe SA;
• przeszkolony personel klienta;
• Personel klienta zaangażowany w eksploatację próbną.

Tym samym iteracyjny sposób realizacji zapewnia dostępność wszystkich kluczowych produktów projektu, tworząc dodatkową wartość w postaci możliwości stałego przeglądu postępów projektu. Cechą metody iteracyjnej jest to, że w wyniku każdej iteracji klient posiada komplet dokumentów, narzędzi automatyzacji i personelu. Dzięki temu zestawowi organizacja ma możliwość dalszego rozwoju systemu zarządzania IT w świetle nowych okoliczności i nowych warunków, aż do wyeliminowania usług zewnętrznego dostawcy.

Wniosek

W artykule omówiliśmy kilka alternatywnych możliwości wdrożenia zautomatyzowanego systemu zarządzania działalnością działu IT. Są to „Rozwiązanie producenta”, „Najlepsza praktyka” i „Rozwiązanie niestandardowe”, które z kolei można rozwijać zarówno w sposób „klasyczny”, jak i „iteracyjny”.

Rozważane opcje różnią się nie tylko cechami jakościowymi. Istnieje znacząca różnica w czasie i kosztach projektu dla klienta pomiędzy podstawową konfiguracją systemu automatyki „po wyjęciu z pudełka” a wdrożeniem kilkukrotnie sprawdzonego rozwiązania „indywidualnego”.

Nie ulega wątpliwości, że dodatkowy czas i zasoby, jakie organizacja poświęca na analizę i wybór metody realizacji na etapie przygotowania projektu, rekompensuje dokładniejsze „trafienie” rezultatów projektu w planowany budżet i oczekiwania interesariuszy.

Powodzenia w Twoich projektach!

W toku prac nad tworzeniem systemów ekspertowych wykształciła się pewna technologia ich rozwoju, obejmująca sześć następujących etapów: identyfikacja, konceptualizacja, formalizacja, wdrożenie, testowanie, eksploatacja próbna i wdrożenie.

W tym artykule omówiono szósty etap: eksploatacja próbna i wdrożenie.

Na etapie eksploatacji próbnej i wdrożenia sprawdzana jest przydatność systemu eksperckiego dla użytkownika końcowego. Tutaj system zajmuje się rozwiązaniem wszystkich możliwych zadań podczas pracy z różnymi użytkownikami. Wskazane jest zorganizowanie działania systemu nie na stanowisku dewelopera, ale w miejscu pracy użytkownika. Do tego etapu należy przejść dopiero wtedy, gdy system, zdaniem eksperta, pomyślnie rozwiąże wszystkie wymagane zadania, aby błędy w decyzjach nie tworzyły negatywnego wizerunku systemu dla użytkownika. O przydatności systemu dla użytkownika decyduje przede wszystkim wygoda pracy z nim oraz jego użyteczność.

Pod przydatność System rozumiany jest jako zdolność systemu w trakcie dialogu do określenia potrzeb użytkownika, identyfikacji i eliminacji przyczyn niepowodzeń w pracy oraz zaspokojenia potrzeb użytkownika (tj. rozwiązania postawionych zadań). Innymi słowy, ważne jest, aby użytkownik „wniósł do świadomości” system, której potrzebuje informacje, pomimo możliwe błędy dozwolone przez niego z powodu niewystarczającej znajomości systemu. Oczywiście dla użytkownika ważna jest również kompletność i poprawność rozwiązań, ale te cechy powinien sprawdzić ekspert na wcześniejszym etapie.

Pod wygoda przez pracę z systemem rozumie się:

• naturalność interakcji z systemem, tj. komunikacja w znanej, nie męczącej dla użytkownika formie;
• elastyczność systemu, tj. możliwość dostosowania systemu do różnych użytkowników, a także uwzględniania zmian w kwalifikacjach tego samego użytkownika;
• tolerancja błędów systemu, tj. zdolność systemu do niepowodzenia w wyniku błędnych działań niedoświadczonego użytkownika.

Na podstawie wyników operacji może być konieczna nie tylko modyfikacja reguł i danych (poprawa lub zmiana języka komunikacji, narzędzia dialogowe, narzędzia do wykrywania i korygowania błędów, dostosowywanie itp.), ale także zmiana I/O urządzeń ze względu na ich nieakceptowalność dla użytkownika. Na podstawie wyników tego etapu podejmowana jest decyzja o zreplikowaniu systemu. Po pomyślnym zakończeniu fazy eksploatacji próbnej i wykorzystaniu systemu ekspertowego przez różnych użytkowników można go zakwalifikować do przemysłowego systemu ekspertowego.

Ogólnie rzecz biorąc, w trakcie próbnej eksploatacji prototypu wymagania dotyczące systemu są doprecyzowane: programiści i użytkownicy mają możliwość bezpośredniego przestudiowania i wyeliminowania konsekwencji podjętych decyzji projektowych. Zasada budowania interfejsu WYSIWYG(To, co widzisz, jest tym, co dostajesz - dostajesz to, co widzisz) pozwala użytkownikowi bezpośrednio ocenić skutki zmian wprowadzonych do prototypu.

Tworzenie systemu informatycznego rozpoczyna się od momentu pierwszych negocjacji pomiędzy Klientem a potencjalnym Wykonawcą i może nigdy się nie skończyć, ponieważ dobre i użyteczne systemy są stale ulepszane i rozwijane.

Wstępny etap

Na tym etapie konieczne jest zrozumienie głównych celów i zadań przyszłego projektu. W tym celu kluczowi przedstawiciele Klienta i Wykonawcy organizują spotkania, na których omawiają koncepcję systemu informatycznego, kluczowe punkty techniczne, terminy i zakres wykonywanych prac oraz koszty i źródła finansowania. Rezultatem etapu wstępnego, oprócz uzgodnionych warunków przyszłej umowy, powinien być pierwszy i najbardziej fundamentalny dokument projektowy - karta projektu.

Karta projektu określa następujące podstawowe punkty związane z procesem tworzenia i wdrażania systemu informatycznego:

• Krótki opis projektu, cele i założenia tworzenia systemu informacyjnego.
• Ogólny opis zakresu prac.
• Granice projektu: terminy, budżet, lista obiektów automatyki.
• Opis produktu: Lista dostarczonego sprzętu i oprogramowanie, rodzaj i liczba licencji itp.
• Struktura organizacyjna projektu: lista i role członków zespołu projektowego po stronie Wykonawcy i Klienta, ich odpowiedzialności i obowiązki, system zarządzania dokumentacją projektową.
• Główne etapy rozwoju i wdrożenia systemu informatycznego, rozszerzony harmonogram ich realizacji.
• Najistotniejsze ryzyka niewypełnienia zobowiązań w ramach projektu, a także sposoby minimalizacji ryzyka.

Innymi słowy, karta projektu to właśnie karta opracowana przez kierownika projektu wraz z głównymi członkami zespołu projektowego, zatwierdzona przez kierownictwo Wykonawcy i Klienta i nie powinna być dostosowywana przez cały czas tworzenia system informacyjny.

Za zakończenie etapu wstępnego można uznać moment podpisania umowy na usługi na wykonanie i wdrożenie systemu informatycznego oraz zatwierdzenie karty projektu.

Zbieranie wymagań

W tym momencie zidentyfikowane zostały wszystkie kluczowe liczby - uczestnicy projektu i nic nie stoi na przeszkodzie, abyśmy przystąpili do zbierania i zatwierdzania wymagań dla przyszłego systemu informatycznego. Przedstawiciele wykonawcy komunikują się z przyszłymi użytkownikami i administratorami systemu, a także z ich kierownictwem. W trakcie badania systematyzowane są nie tylko wymagania i życzenia dotyczące wdrożonego rozwiązania, ale również analizowana jest dokumentacja, która powinna stać się źródłem danych początkowych systemu lub w efekcie której tworzenie powinno zostać zautomatyzowane.

Ten krok powinien skutkować zakres zadań za opracowanie i wdrożenie systemu informatycznego. SIWZ powinna opierać się na warunkach umowy i wymaganiach określonych w karcie projektu i zawierać następujące sekcje (w przypadku Rosji strukturę SIWZ reguluje GOST 34.602 89):

• Cel i cel tworzenia systemu.
• Opis obiektu automatyzacji i głównych zautomatyzowanych procesów biznesowych.
• Wymagania systemowe: wymagania konstrukcyjne; funkcje (zadania) rozwiązywane przez system; wymagania dotyczące wsparcia technicznego i organizacyjnego; wymagania dotyczące niezawodności, bezpieczeństwa itp. itp.
• Skład i treść pracy nad stworzeniem systemu informatycznego.
• Kolejność kontroli i akceptacji wyników pracy.
• Wymagania dotyczące zakresu prac przygotowania obiektu automatyki do uruchomienia systemu informatycznego.
• Wymagania dotyczące składu dokumentacji projektowej i użytkowej.

Zakończeniem etapu zbierania wymagań jest akceptacja SIWZ przez Klienta. W niektórych przypadkach przed rozpoczęciem prac nad projektem Klient posiada już specyfikację istotnych warunków zamówienia (zawartą w dokumentacja przetargowa). W takim przypadku wyniki ankiety i zbioru wymagań są rejestrowane w prywatnych warunkach odniesienia, uszczegóławiających i konkretyzujących Ogólne wymagania do systemu informacyjnego przedstawionego w pierwotnym zakresie zadań.

Projekt

Na tym etapie staraniem Wykonawcy szczegółowo projektowane są wszystkie scenariusze związane z opracowaniem i wdrożeniem systemu informatycznego na terenie Klienta. Odbywa się to zgodnie z warunkami środowiska informacyjnego (krajobrazu systemowego) Klienta oraz wymaganiami integracji tworzonego systemu z innymi już dostępnymi i obsługiwanymi przez Klienta. produkty oprogramowania. Wynikiem fazy projektowania powinien być projekt następujących sekcji projekt techniczny (koncepcyjny):

• Architektura systemu informacyjnego.
• Opis struktur przechowywania informacji (baz danych).
• Zaprojektuj rozwiązania przedstawione poprzez szczegółowy opis scenariuszy automatyzacji dla wszystkich procesów biznesowych, na które ma wpływ wdrożenie systemu.
• Scenariusze integracji opracowanego systemu informatycznego z zewnętrznymi produktami oprogramowania.
• Źródła danych początkowych i opcje początkowej zawartości informacyjnej systemu.
• Koncepcja zróżnicowania praw dostępu do danych w oparciu o role użytkowników, które określają m.in. ich uprawnienia.
• Koncepcja szkolenia użytkowników systemu informatycznego.

Realizacja

Etap realizacji wszystkich wymagań dla systemu informatycznego określonych w SIWZ i Projekcie Technicznym. W tym okresie Wykonawca opracowuje wszystkie niezbędne komponenty oprogramowania, tworzy struktury baz danych, instaluje, konfiguruje i testuje wszystkie komponenty systemu informatycznego na swoim terenie, symuluje scenariusze integracji itp. itp. Zakończenie fazy wdrożeniowej potwierdza pojawienie się m.in dokumenty projektowe jako przewodnik po instalacji i konfiguracji systemu, program i procedura testowa systemu, a także szablon bazy danych i rejestr wszystkich zrealizowanych opracowań oprogramowania.

Przygotowanie systemu informatycznego do eksploatacji

Wszystkie prace tego etapu są już wykonywane u Klienta i obejmują instalację i konfigurację wszystkich elementów systemu w środowisku informacyjnym Klienta, wstępne testy, opracowanie dokumentacji użytkownika, szkolenie użytkowników, wczytywanie danych początkowych, testowanie zgodnie z program i metodologia oraz inne prace przygotowawcze.

Do czasu zakończenia wszystkich prac przygotowawczych należy opracować i zatwierdzić procedurę operacyjną systemu. W szczególności rozporządzenie powinno określać użytkowników i ich role w systemie, zgodnie z ich obowiązkami zawodowymi.

Działanie pilota

Ostatni etap rozwoju i wstępne wdrożenie systemu informacyjnego, którego zadaniem jest pomyślne przeprowadzenie przez określony czas próbnej eksploatacji systemu, a celem jest potwierdzenie, że stworzony system informacyjny jest dokładnie takim wynikiem, że Oczekiwany klient.

W tym okresie użytkownicy rozpoczynają obsługę systemu zgodnie z regulacjami opracowanymi na poprzednim etapie. Podczas operacji pilotażowej naprawiane są błędy i uzgadniane są niezbędne ulepszenia. Wykonawca usuwa błędy, wprowadza usprawnienia i pod warunkiem, że system zacznie funkcjonować zgodnie ze wszystkimi przedstawionymi mu wcześniej wymaganiami, na koniec ustalonego okresu otrzymuje protokół z pomyślnego zakończenia operacji pilotażowej.

Wraz z zakończeniem operacji pilotażowej z reguły kończy się umowa na stworzenie systemu informatycznego. Sam system trafia do komercyjnej eksploatacji, a Wykonawca, jeśli Klient jest tym zainteresowany, zawiera odrębną umowę na jego utrzymanie, na okres ustalony warunkami umowy.

Utrzymanie i rozwój systemu

Eksploatacja przemysłowa może ujawnić, że niektóre wymagania dla tworzonego systemu informacyjnego zawierają nieścisłości i wymagają innego sformułowania lub uzupełnień, a sam system wymaga udoskonalenia. Nie każdy Klient posiada w swojej kadrze kadrę, która jest w stanie samodzielnie wprowadzić do systemu wszelkie zmiany podyktowane realną sytuacją, dlatego zawiera z Wykonawcą odrębną umowę na utrzymanie systemu informatycznego.

Użytkownicy systemu informatycznego zaczynają komunikować się z przedstawicielami obsługi klienta, którzy otrzymują od nich prośby o poprawę funkcjonalności i usuwanie usterek, przekazują zgłoszenia do pracy i okresowo powiadamiają użytkowników o statusie swojego zgłoszenia. Lista możliwych usprawnień oraz procedura rozpatrywania wniosków jest określona warunkami umowy. Jeżeli zachodzi potrzeba pracy, która nie mieści się w istocie umowy o wsparcie, wówczas Klient i Wykonawca sporządzają odrębną umowę na ten gatunek prace, które już można przypisać pracom nad modernizacją i rozwojem eksploatowanego systemu informatycznego.

Testy wstępne

Wstępne testy EIS mogą być autonomiczne i złożone.

Program testów autonomicznych wskazuje:

lista funkcji do przetestowania;

opis relacji obiektu testowego z innymi częściami EIS;

warunki, procedura i metody przeprowadzania testów i przetwarzania wyników;

· Kryteria akceptacji części na podstawie wyników testów.

Do programu testów offline należy dołączyć harmonogram testów offline.

Przygotowane i skoordynowane testy (przypadki testowe) na etapie testów autonomicznych powinny zapewnić:

Pełne sprawdzenie funkcji i procedur zgodnie z listą uzgodnioną z klientem;

niezbędną dokładność obliczeń, ustaloną w TOR;

Sprawdzenie głównych charakterystyk czasowych funkcjonowania oprogramowania;

Sprawdzanie niezawodności i stabilności działania oprogramowania i sprzętu.

Wyniki testów autonomicznych części EIS są zapisywane w raportach z testów. Protokół musi zawierać wniosek o możliwości dopuszczenia części EIS do złożonych badań. Jeżeli przeprowadzone testy autonomiczne okażą się niewystarczające lub ujawnione zostanie naruszenie wymagań dokumentów regulacyjnych dotyczących składu lub treści dokumentacji, określona część EIS może zostać zwrócona do rewizji i wyznaczona nowy semestr testy.

Kompleksowe testy EIS przeprowadza się poprzez wykonanie złożonych testów. Kompleksowy test powinien:

być logicznie połączonym;

· zapewnienie kontroli działania funkcji części EIS we wszystkich trybach pracy;

· zapewnienie kontroli reakcji systemu na błędne informacje i sytuacje awaryjne.

Wyniki testu znajdują odzwierciedlenie w protokole. Praca kończy się wykonaniem świadectwa odbioru do eksploatacji próbnej.

W programie kompleksowych testów EIS wskaż:

lista obiektów testowych;

skład przedłożonej dokumentacji;

opis relacji, które mają być testowane między obiektami testowymi;

kolejność testowania części EIS;

· procedurę i metody testowania, w tym skład oprogramowania i sprzętu wymaganego do testowania, w tym specjalne stanowiska i stanowiska testowe.

Zintegrowany protokół z badań powinien zawierać wniosek o możliwości (niemożliwości) przyjęcia EIS do eksploatacji próbnej, a także listę niezbędnych usprawnień i zalecanych terminów ich wdrożenia.

Operacja próbna przeprowadzana jest zgodnie z programem, który wskazuje:

warunki i procedura funkcjonowania części EIS i EIS jako całości;

· czas trwania eksploatacji próbnej, wystarczający do weryfikacji prawidłowego funkcjonowania EIS;

Procedura usuwania braków stwierdzonych podczas eksploatacji próbnej.

Podczas próbnej eksploatacji EIS prowadzony jest dziennik pracy, w którym wprowadzane są informacje o czasie eksploatacji EIS, awariach, awariach, awariach, zmianach parametrów obiektu automatyki, bieżących korektach dokumentacji oraz oprogramowanie, dostosowanie i środki techniczne. Informacje są zapisywane w dzienniku z datą i odpowiedzialna osoba. Dziennik może zawierać komentarze personelu dotyczące łatwości obsługi EIS.

Na podstawie wyników eksploatacji próbnej podejmowana jest decyzja o możliwości przedstawienia części EIS i systemu jako całości do testów akceptacyjnych.

Prace kończą się wykonaniem aktu o zakończeniu eksploatacji próbnej i dopuszczeniu systemu do testów odbiorczych.