REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI WYTYCZNE DO MODELU GRZEGORZ RDUCH
Rekomendacje dotyczące Platformy Zarządzania Kompetencjami 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 of requests per minute 250 Maximum latency (browser rendering time)* seconds 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 PostgreSQL 5. Uwagi ogólne