GRAPE Dokumentacja rozwiązania 1.0

Transkrypt

GRAPE Dokumentacja rozwiązania 1.0
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...)
Zakładka [Foldery], grupa Struktura Organizacyjna
Podmioty zewnętrzne
Prosta lista podmiotów zewnętrznych do których będą przypisany elementy
zewnętrzne modelu
Zakładka [Foldery], grupa Podmioty Zewnętrzne
Procesy
Hierarchiczna lista procesów. Ta lista nie zawiera działań.
Zakładka [Foldery], grupa Procesy.
Resource
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]
Podmioty obce
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]
Activity
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
Zakładka [Elementy-działania]
Outputs
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
Zakładka [Elementy-outputs]
Relacje Execute
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)
Dane wprowadzane przez Modelera Działowego.
Authors
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 Dla każdej wersji modelu, dla każdego okresu, trzeba uruchomić funkcję
(100%)
generowania ankiet. Dla każdego RESOURCE przygotowany jest
szablon ankiety w postaci pliku XML. W okresie ankietowania te dane
prezentowane są użytkownikom.
Dodaj nowy
okres
(100%)
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:
1.

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.
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%)
Przygotowanie struktur danych dedykowanych dla analiz i raportów.
Przeliczenie dla każdego okresu raportowania.
Kasuj okres
(100%)
Usunięccie kompletu danych (struktura + dane) dla wskazanego okresu.
Kopiuj okres
(0%)
Kopiowanie danych pomiędzy okresami przetwarzania. Kopiowanie
struktury i wartości.
Load script
(100%)
Wykonanie skryptu
Przeglądanie i
budowa modelu
(0%)
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%)
Ekran modelera działowego.
Brakuje
•
•
funkcji dodawania nowych outputów.
funkcji wskazania odbiorcy działania (elementu RESOURCE)
Analizy i Raporty Brak wymagań.
(10%)
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\jboss4.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
•

Podobne dokumenty