GRAPE Dokumentacja rozwiązania 1.0
Spis treści 1. Opis systemu...3 2. Struktura modelu...3 2.1. Folder...3 2.2. Item...3 2.3. Relations...3 3. Struktura modelu PAM...4 3.3. Podmioty zewnętrzne...5 3. Zasilanie modelu...5 4. Przetwarzanie...5 4.1. Użytkownicy modelu...5 4.1.1. administrator merytoryczny...6 4.1.2. modeler działowy...6 4.1.3. weryfikator...6 4.1.4. pracownik...6 5. Analizy i Raporty...6 9. Instalacja...7 X. Issues...9
1. Opis systemu Grape jest rozwiązaniem dedykowanym do budowy modeli danych dla różnych przetwarzań klasy Business Intelligence. Model systemu GRAPE definuje obiekty oraz relacje pomiędzy nimi. Każda definicja struktury modelu jest przypisana do wymiaru czas, co pozwala na implementację zmian modelu w czasie. Każda wersja modelu jest przypisana do elementu wymiary czas. W ten sposób modele Grape są automtycznie wersjonowane czasem (nawet gdy nie ma zmian). Modele Grape uzupełnione o różne algorytmy przetwarzania pozwalają na implementację rozwiązań takich jak: 1. modele kosztowe ABC pełen modele lub time driven ABC 2. modele analizy procesów 3. modele ABB 4. modele BSC (model strategii, incjatyw, itd...) 2. Struktura modelu 2.1. Folder Służy do zapisu list hierarchicznych. Przykładowe zastosowania to: Struktura organizacyjna Procesy Model wymaga definicji kategorii folderów. 2.2. Item Zapis szczegółowych struktur modelu. Każy item przypisany musi być do struktury typu folder. Model wymaga definicji kategorii elementów (item). 2.3. Relations Powiązanie pomiędzy elementami typy Items. Każda relacja jest przypisana do definiowanej przez model kategorii.
3. Struktura modelu PAM Supplier Organization Structure Resources Outputs Consumer Supplier Relations (who does what) Inputs Consumer Processes (hierarchical) Activities Outputs/Inputs Struktura organizacyjna Hierarchiczna lista jednostek firmy (piony, departamenty itd...) Podmioty zewnętrzne Zakładka [Foldery], grupa Struktura Organizacyjna Prosta lista podmiotów zewnętrznych do których będą przypisany elementy zewnętrzne modelu Zakładka [Foldery], grupa Podmioty Zewnętrzne Procesy Resource Podmioty obce Activity Hierarchiczna lista procesów. Ta lista nie zawiera działań. Zakładka [Foldery], grupa Procesy. Lista jednostek organizacyjnych dla których wykonywana jest analiza PAM. Dla jednostek z grupy Resource dostępne będą ankiety Grape oraz szczegółowa ewidencja danych. Jest to lista płaska bez dodatkowej hierarchii. Każda jednostka musi być przypisana do jednostki organizacyjnej zdefiniowanej w Strukturze organizacyjnej. Zakładka [Elementy-resource] Lista zewnętrznych podmiotów, które mogą wystąpić jako dostawcy WEJSCIA lub odbiorcy WYJŚCIA działań realizowanych w ramach procesów organiacji. Podmioty obce nie są objęte ankietowaniem. Zakładka [Elementy-podmioty_obce] Lista działań wykonywanych w ramach procesów organizacji. Wprowadzona w tym miejscu lista tworzy podstawowy słownik działań, które będą podstawą do ankietowania. Tylko dla tych działań możliwe będzie definiowanie wejścia/wyjścia (input/output) i miar ilościowych oraz jakościowych. Każde działanie musi być przypisane do procesu. Atrybut typ może przyjmować dwie wartości: 1=unique
2=shared Outputs Zakładka [Elementy-działania] Rezultaty działań. Do jednego działania może być przypisane wiele elementów typu Output. Wymagany parametr dla każdego elementu Output to Teoretyczna pracochłonność jednostkowa. Parametr Rodzaj może przybrać dwie wartości 1 shared/podzielny 2 unique/niepodzielny Output shared mogą być przypisane do wielu działań. Output unique może być przypisany tylko do jednego działania. Uwaga: Aktualna wersja obsługuje tylko Output=unique Relacje Execute Zakładka [Elementy-outputs] Podstawowy rodzaj relacji pomiędzy elementami Resource a Activity. Relacja wskazuje działania wykonywane przez daną jednostkę organizacyjną (Zasób). Na podstawie tych relacji powstaje struktura ankiety dla pracowników. Outputs-Suppliers Dane od Dostawców wyników działań. Jest to zapis wyników działań wraz z oceną jakościową. Dane te są podstawą do wyliczenia modelu w zakresie rzeczywiście dostarczonych rezultatów ilościowo i jakościowo. Każdy rezultat jest opisany trzema parametrami: ilość wyprodukowana (ilość deklarowana przez dostawcę, może być inna niż ilość deklarowana przez odbiorcę w sekcji Inputs) ocena użyteczności rezultatów (ocena dostawcy) (quantity score) ocena jakości rezutlatów (ocena dostawcy) (quality score) Dane wprowadzane są tylko przez tzw. Modelera Działowego, czyli osobę wprowadzającą dane na poziomie jednostki opisanej jako Resource. Najczęściej będzie to kierownik działu lub departamentu lub osoba przez niego delegowana. Inputs-Consumers Dane Odbiorców wyników działań. Jest zapis wyników ilościowych i jakościowych z punktu widzenia odbiorcy.. Podobnie jak w przypadku danych Dostawców rezultat jest opisany trzema parametrami: ilość wykorzystana (ilość deklarowana przez idbiorcę, może być inna niż ilość deklarowana przez dostawcę) ocena użyteczności rezultatów (ocena odbiorcy) (quantity score) ocena jakości rezutlatów (ocena odbiorcy) (quality score) Authors Dane wprowadzane przez Modelera Działowego. Największa grupa użytkowników, edytorzy ankiet. Dla każdej osoby wymagane jest podanie wymiaru etatu. Jednostki organizacyjnej z kategorii RESOURCE symbol Modelera Działowego (też musi być wprowadzony do AUTHORS)
3. Zasilanie modelu 4. Przetwarzanie 4.1. Użytkownicy modelu 4.1.1. administrator merytoryczny nadania uprawnień użytkownikom nadania nazw szczeblom organizacyjnym (np. przechrzcić nazwę szczebla komórka na dział ) definiowania okresów definiowania struktur zasobów i procesów / działań przypisywanie wykonawcy do działania (działanie może mieć tylko jednego wykonawcę) wprowadzania inputów i outputów dla działań definiowania atrybutów i przypisywania ich do zasobów i procesów/działań wprowadzania wartości atrybutów dla procesów/działań, inputów i outputów wprowadzanie wartości kosztów i etatów dla komórek 4.1.2. modeler działowy jest uprawnieniem ograniczonym do zasobów i działań danej komórki organizacyjnej (np. Kowalskiemu nadaje się takie uprawnienie w zakresie działu X i Y). Uprawnienie to może dotyczyć tylko jednego lub kilku wybranych okresów (tj. możesz mieć uprawnienie do działu X w zakresie okresów obliczeniowych styczeń i luty a w zakresie okresu marzec to już nie). Modeler działowy (uprawnienie do Działu X) ma możliwość dodawać nowe działania system musi umożliwiać wyłączenie tej opcji przypisywać wykonawcę do działania, o ile działanie nie ma wykonawcy (system umożliwi jedynie wskazanie Działu X jako wykonawcy) - system umożliwiać wyłączenie tej opcji usuwać / edytować działanie, dla których wykonawcą jest Dział X system musi umożliwiać
wyłączenie tej opcji wprowadzać inputy i outputy dla działań, dla których wykonawcą jest Dział X wprowadzać wartości atrybutów dla inputów i outputów dla działań, dla których wykonawcą jest Dział X 4.1.4. pracownik Jedyna operacja to edycja ankiet. 4.2 Funkcje aplikacji Grape dla modelu PAM Administrator MODELU Generator ankiet (100%) Dodaj nowy okres (100%) Dla każdej wersji modelu, dla każdego okresu, trzeba uruchomić funkcję generowania ankiet. Dla każdego RESOURCE przygotowany jest szablon ankiety w postaci pliku XML. W okresie ankietowania te dane prezentowane są użytkownikom. Kopia aktualnej sturktury modelu do nowego okresu. Jest to równoważne z przygotowaniem nowej wersji modelu. Przetwarzanie ankiet (50%) Zebranie czasów osobowych z ankiet i sumowania na poziomie działu dla potrzeb raportowych i analitycznych. Przetwarzanie dla każdego okresu raportowania Liczone są następujące wartości: pracochłonność alokowana - wynikająca z rozpisania czasu pracy przez pracowników pracochłonność teoretyczna - wyliczana przez pomnożenie ilościowych wolumenów efektów działań (outputów) i jednostkowych normatywów pracochłonności. 1. Skąd się bierze pracochłonność alokowana? Punktem wyjścia jest alokacja czasu pracy przez pracowników. Pracownik Kowalski z Działu X jest zatrudniony w określonym wymiarze etatowym np. na pół etatu. Pracownik zadeklarował, że na działanie Wysyłka poczty przeznacza 20% swojego łącznego czasu pracy, w tym wypadku będzie to 20% x 0,5 etatu = 0,10 etatu. Z Działu X rozpisali swój czas pracownicy zatrudnieni łącznie w wymiarze 24 etatów. Całkowite zatrudnienie w tym dziale to 26 etatów (dwóch się nie rozpisało na działania ). Poprzez przydzielenie procentów pracownicy Działu X przypisali łącznie 3,75 etatu do działania Wysyłka poczty. System pamięta, że z tego działu rozpisało się jedynie 24 spośród 26 etatów. Dlatego
system powiększy zadeklarowane zaangażowanie etatowe w działaniu Wysyłka poczty (i w każdym innym działaniu) wg wskaźnika 26/24 (ekstrapolacja). Tym samym zaangażowanie etatowe Działu X w działanie Wysyłka poczty wynosić będzie 3,75 etatu x 26/24 = 4,0625 etatu. Całkowite zaangażowanie w działanie będzie sumą zaangażowań ze wszystkich komórek organizacyjnych. 2. Skąd się bierze pracochłonność teoretyczna? Jak już wcześniej napisano pracochłonność teoretyczna jest wynikiem iloczynu wolumeny jednostkowych pracochłonności efektów działań i wolumenów ilości tych efektów: pracochłonność teoretyczna w skali roku = = pracochłonność jednostkowa w roboczominutach na jednostkę outputu x liczba jednostek outputu w skali roku Przygotowanie kostek OLAP (100%) Kasuj okres (100%) Kopiuj okres (0%) Load script (100%) Przeglądanie i budowa modelu (0%) Przygotowanie struktur danych dedykowanych dla analiz i raportów. Przeliczenie dla każdego okresu raportowania. Usunięccie kompletu danych (struktura + dane) dla wskazanego okresu. Kopiowanie danych pomiędzy okresami przetwarzania. Kopiowanie struktury i wartości. Wykonanie skryptu Funkcje pozwalające administratorowi na dowolne zmiany struktury modelu analogiczne jak definiowane w akruszu MS Excel służącym do zasilenia modeli prototypowych. PRACOWNIK Survey (100%) Prezentacja ankiet. Jedno poziomowa hierarchia kontroli. Pracownikmanager. MODELER DZIAŁOWY Edycja Inputs/Outpus (50%) Analizy i Raporty (10%) Ekran modelera działowego. Brakuje funkcji dodawania nowych outputów. funkcji wskazania odbiorcy działania (elementu RESOURCE) Brak wymagań. Aktualne analize to są tylko przykłady. 5. Analizy i Raporty
9. Instalacja Kroki instalacji: 1.Rozpakować Grape_pack.zip do katalogu C:\grape_pack 2. Katalgo c:\grape_pack\grape. Otworzyć do edycji pliki Start.bart, stop.bat ustawić nazwę serwera i katalogu macierzystego. Nazwa serwera to nazwa komputera, katalog macierzysty to c:\grape_pack\grape. Miejsca do podmiany są wskazane czerwonym kolorem @echo off set GRAPE_PATH=c:\grape_pack\Grape\ set JAVA_HOME=%GRAPE_PATH%jre set PATH=%GRAPE_PATH%jre\bin;%PATH%; cd data start start_hypersonic.bat cd..\..\jboss-4.2.3.ga\bin start run.bat -b malin <lines.txt 3.Otworzyć do edycji plik c:\grape_pack\jboss-4.2.3.ga\server\default\deploy\pentaho.ear\pentaho.war\web-inf\web.xml i zamienić parametry zaznaczone na czerwono: d:\solutions na c:\grape_pack SpinNote na nazwę serwera (komputera) <context-param> <param-name>solution-path</param-name> <param-value>d:\solutions\grape\pentaho-solutions</param-value> </context-param> <!-- <context-param> <param-name>pentaho-system-cfg</param-name> <paramvalue>c:/tmp/test_pentaho.xml</param-value> --> </context-param> <context-param> <param-name>base-url</param-name> <param-value>http://spinnote:8080/pentaho/</param-value> </context-param>
4.Otworzyć do edycji plik run.bat z katalogu c:\grape_pack\jboss-4.2.3.ga\bin wpisać prawidłową ścieżkę dostępu do katalogu Grape. Do zmiennej GRAPE_PATH. set GRAPE_PATH=c:\grape_pack\Grape\ set JAVA_HOME=%GRAPE_PATH%jre set PATH=%GRAPE_PATH%jre\bin;%PATH%; 5.Rozpakować plik c:\grape_pack\boss-4.2.3.ga\server\default\deploy\grape.ear do katalogu Grape. (Program 7-zip potrafi rozpakować plik EAR oraz WAR) 6.Skasować plik grape.ear 7.Zmienić nazwę katalogu Grape na Grape.ear 8.Rozpakować plik C:\grape_pack\jboss-4.2.3.GA\server\default\deploy\Grape.ear\GrapeSurvey.war do katalogu GrapeSurvey 9.Skasować plik GrapeSurevey.war 10.Zmienić nazwę katalogi GrapeSurvey na GrapeSurvey.war 11.Otworzyć do edycji C:\grape_pack\jboss- 4.2.3.GA\server\default\deploy\Grape.ear\GrapeSurvey.war\WEB-INF\web.xml i wpisać aktualne parametry dla GrapePath oraz grape.pentaho Miejsca do podmiany są zaznaczone czerwonym kolorem <context-param> <description>katalog macierzysty Grape</description> <param-name>grape.folder</param-name> <param-value>c:\grape_pack\grape\system</param-value> </context-param> <context-param> <description>katalog grape pentaho</description> <param-name>grape.pentaho</param-name> <param-value>c:\grape_pack\grape\pentaho-solutions</param-value> </context-param> </web-app> 12. Uruchomienie serwera Uruchomić start.bat z katalogu c:\grape_pack\grape Uruchomienie serwera 1-5 minut zależy od mocy maszyny. 13. Uruchomienie aplikacji Otworzyć przeglądarkę i wpisać adres http://<nazwa komuptera>:8080/gs użytkownik administrator: Kosak, hasło: password użytkownik zwykły: ala01 hasło: password
X. Issues x.1 Kto może dodać podmiot zewnętrzny? Czy modeler departamentalny? x.2 Przyjmowanie efektów działań przez odbiorców (jako inputy) powinno się podbywać w drugiej fazie, tj. po zamodelowaniu działań własnych i ich outputów (organizacyjnie, bo technicznie może być możliwe cały czas) x.3 Działania mogą mieć charakter: unique (może je wykonywac tylko 1 komórka) lub shared (może je wykonywac wiele komórek) x.4 Działanie unique jest wykonywane przez tą komórkę, która pierwsza zostanie do niego przypisana x.5 Działanie shared może być dodane jedynie przez administratora merytorycznego x.6 Działanie dodawane przez modelera oddziałowego ma z założenia charakter unique x.7 Generalnie: działania Centrali będą miały charakter unique, działania Sieci będą miały charakter shared x.8 Dla foldera można wskazac, czy modeler departamentalny może w nim dodawać nowe działania czy nie (przenosi się to na sub-foldery). Jeśli modeler departamentalny nie może, to może jedynie administror biznesowy x.9 Dla działań dzielonych outputy są z góry zdefiniowane (przez administratora merytorycznego) x.10 W ramach działania shared każdy modeler deparamentowy dodaje ilość outputu, który wyprodukowała jego komórka (system rozpoznaje, potrafi też sumowac z wszystkich komórek) x.11 Output może mieć charakter podzielny lub niepodzielny Wskazując odbiorców (o ile więcej niż jeden) outputu podzielnego modeler departamentowy rozdziela na nich ilość. Jeśli output jest niepodzielny system sam przypisuje łączną ilość outputu każdemu odbiorcy. x.12 Output przypisywany jest do (alternatywnie): odbiorcy wewnętrznego (w tym do damego siebie tj. "na potrzeby własne") odbiorcy zewnętrznego (w tym klienta) nie jest przypisywany (na razie nie wprowadzamy przypisań do innych obiektów kosztowych: kanałów dystrybucji, produktów -CHYBA...) x.13 Dodać kontrolę poprawności modelu. Sprawdzić trzeba czy dany output nie jest przypisany do dwóch różnych działań. W aktualnej wersji to jest niedozwolone. x.14 Tego poniżej na razie nie wprowadziłem - być może jest to opcja na przyszłość... Outputy też mają charkter: unique lub shared Unique odnoszą się tylko do jednego działania Shared mogą być wykorzystywane w różnych działaniach W działaniach typu unique mogą występować jedynie outputy unique W działaniach typu shared mogą występować zarówno outputy unique jak i shared