rekomendacje dotyczące platformy zarządzania kompetencjami

REKOMENDACJE DOTYCZĄCE
PLATFORMY ZARZĄDZANIA KOMPETENCJAMI
WYTYCZNE DO MODELU
GRZEGORZ RDUCH
Rek o me n d ac je do t ycz ąc e P l at fo r my Z a rz ądz a n i a K om p et en c j am i
1. Rekomendacje odnośnie warstwy biznesowej narzędzia
Sugerujemy opracowanie rozwiązania opartego na następujących narzędziach:
1. W odniesieniu do komponentu służącego budowaniu strategii:
a. definicje wizji i misji firmy
b. analiza SWOT
c. uproszczona / zmodyfikowana wersja Strategicznej Karty Wyników (BSC) zawierająca
określenie:
- krytycznych obszarów biznesu,
- celów strategicznych,
- celów szczegółowych oraz
- działań
Uwagi
Rozwiązanie informatyczne powinno uwzględnić zależności zachodzące między
poszczególnymi elementami SKW, zarówno na poziomie generowania odpowiedzi jak
i raportów podsumowujących.
2. W odniesieniu do komponentu służącego do zarządzania kompetencjami:
a. tabela zasobów
b. opisy stanowisk pracy > opisy działań na stanowiskach pracy (TDRs)
c. tabela kompetencji
d. tabela sukcesji
e. tabela zasobów do intermentoringu
f. plan działań mających na celu likwidację luki kompetencyjnej / plan sukcesji
Uwagi ad. 1 i 2. powyżej
Ograniczyć liczbę narzędzi udostępnionych na platformie w wersji podstawowej (MVP);
wybrać minimalistyczny zestaw narzędzi, które pozwalają na realizację flow
zaproponowanego we Wniosku (budowanie strategii i zarządzanie kompetencjami);
w przypadku zainteresowania ze strony użytkowników, można w przyszłości / w drugim
etapie realizacji projektu rozważyć poszerzenie katalogu narzędzi udostępnionych
w rozwiązaniu.
2. Rekomendacje odnośnie funkcjonalności Platformy
Platforma składa się z dwóch niezależnych* komponentów:
a. komponent do budowania strategii firmy
b. komponent do zarządzania kompetencjami firmy, w tym moduł do zarządzania
działaniami w zakresie intermentoringu
W trakcie tworzenia opisu działań dla stanowiska pracy w komponencie do zarządzania
kompetencjami, istnieje techniczna możliwość pobrania tych działań przez użytkownika z
listy działań utworzonej w komponencie do budowania strategii. Problemy:
- działania generowane w trakcie prac nad strategią nie pokrywają wszystkich działań
wykonywanych w toku działalności firmy;
- lista działań generowanych z komponentu dot. strategii może być względnie długa, co
utrudnia zapewnienie właściwego User Experience.
1. Komponent dot. strategii
System ma charakter coachingowy – stawia pytania, które pozwalają przejść przez
ścieżkę tworzenia strategii. Użytkownik / użytkownicy definiują strategię firmy
odpowiadając na pytania. Mniej wprawieni mają dostęp do podpowiedzi w postaci
definicji, objaśnień, sugestii, przykładów (wpisanych na sztywno).
Ad. 1 i 2
Wszelkie dane / informacje wprowadzane są przez użytkowników jednorazowo i
wykorzystywane w pozostałych częściach komponentu. (Jeżeli chodzi o przepływ
informacji między dwoma głównymi komponentami - patrz uwagi powyżej).
Istnieje możliwość generowania raportów (pdf). W przypadku komponentu do
zarządzania kompetencjami - zarówno zbiorczych, jak i indywidualnych. Istnieje
możliwość wydruku lub rozesłania raportów drogą elektroniczną.
3. Rekomendacje dotyczące organizacji projektu (zarządzanie)
Pomimo specyficznych uwarunkowań wynikających z charakteru finansowania projektu
(fundusze unijne) sugerujemy zastosowanie metodyki Lean Product Development. W
szczególności,
* określenie ogólnego zakresu projektu,
* doprecyzowanie wymagań i opracowanie Specyfikacji Technicznej,
* określenie wagi poszczególnych funkcjonalności / cech (features) systemu (zasadniczo
poprzez cost-benefit analysis)
* ustalenie priorytetów w odniesieniu do kolejności implementacji poszczególnych
funkcjonalności
* podział projektu na etapy z uwzględnieniem powyższych
* implementację prowadzoną w oparciu o informacje zwrotne przekazane przez
użytkowników systemu (w drugim etapie realizacji); Proponuję przyjąć strategię
współpracy z docelowym odbiorcą / użytkownikiem, w której projekt podzielony jest na
etapy. Każdy etap powinien dostarczać istotną wartość biznesową.
Zwrócić uwagę na testy automatyczne. Upraszczają one dokonywanie dużych
modernizacji systemu i powodują że produkt będzie możliwy do rozszerzania wraz z
lepszym zgłębianiem dziedziny projektu i potrzeb użytkowników.
4. Rekomendacje dotyczące aspektów technologicznych
Modułowa architektura systemu
Uprawnienia dostępu
Firmy stosują bardzo różne praktyki w zakresie dostępu do informacji. Trudno byłoby
zapewnić rozwiązanie zapewniające elastyczność na tyle dużą, by wszystkie tego typu
praktyki uwzględnić. Wstępnie proponujemy uproszczenie struktury dostępu przez
dokonanie podziału na dwie zasadnicze grupy użytkowników:
* kierownictwo
* wszyscy pracownicy firmy
Klient powinien mieć użytkowników o zróżnicowanym stopniu uprawnień. Z wymogów
projektu wydaje się że wystarczy podział na role:
- admin (np. pracownik IT)
- manager (np. dyrektor, pracownik HR)
- member (np. pracownik)
System powinien cechować się przede wszystkim: intuicyjnością i bezpieczeństwem
danych.
Można zastosować standardowy interfejs http://twitter.github.com/bootstrap
Każdy klient powinien mieć swoją poddomenę np selleo.cmp.pl
Domena powinna decydować o tym do której części bazy danych ma dostęp użytkownik
(można zastosować strategię sugerowaną w
http://blog.jerodsanto.net/2011/07/building-multi-tenant-rails-apps-with-postgresqlschemas/ ).
Wydajność systemu:
Nawet przy dużym zainteresowaniu grupy docelowej, nie zachodzi ryzyko dużego
(sezonowego) obciążenia platformy. Procesy planowania strategicznego / HR
przeprowadzane są względnie rzadko; nie są również prowadzone we wszystkich firmach
w tym samym czasie. Dlatego proponujemy przyjąć następujące wymagania
niefunkcjonalne.
Performance parameter
Unit
Target
Availability
% time
99,75
%
Throughput
number
minute
Maximum
time)*
latency
(browser
of
requests
rendering seconds
per 250
5
Average request duration (server side)
seconds
1
Concurrent users
number
20
*varies between browsers and end user internet connectivity
Resource Type
Unit
Value
CPU
GHz
2,4ghz Xeon X3430
Memory
GB
8
Database
5. Uwagi ogólne
PostgreSQL