Polsko-Japońska Wyższa Szkoła Technik Komputerowych,

Warszawa

Tworzenie Portali Biznesowych

Wykład 2 Systemy zarządzania treścią (cd.)

Wykładowca: dr hab. inż.

Kazimierz Subieta

profesor PJWSTK [email protected]

http://www.ipipan.waw.pl/~subieta

Cechy CMS: zarządzanie wiedzą

knowledge management

   Obejmuje wszystkie aspekty związane z rejestrowaniem, dokumentowaniem oraz wykorzystaniem wiedzy pracowników firmy.

Wiedza dzieli się na:  Wiedzę jawną, bezpośrednio zapisaną w dokumentach, plikach i bazach danych;  Wiedzę cichą, będącą własnością ludzi - pracowników firmy  Wiedza cicha jest zdobywana w praktyce, jest kwintesencją doświadczenia, wyczucia, asocjacji, uświadomionych lub nieuświadomionych poglądów, trenowanych umiejętności rozpoznawania spraw i sytuacji, itd. Wiedza cicha jest kluczowym strategicznym czynnikiem decydującym o konkurencyjności organizacji na rynku.  Wiedza cicha, mimo że tkwiąca w umysłach poszczególnych osób, jest wiedzą obiektywną - może być sprawdzana, testowana i badana empirycznie ze względu na jej jakość i skuteczność.

 Z punktu widzenia organizacji jest więc istotne, aby wprząc tę indywidualną wiedzę pracowników w ogólną kulturę organizacyjną, do której oni należą. K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 2

maj 2002

Zalecenia w zakresie zarządzania wiedzą

       Skupienie się na wiedzy cichej. Niedocenianie, ignorowanie tej wiedzy może mieć negatywne konsekwencje dla konkurencyjności organizacji.

Nacisk na kolektywną bazę wiedzy całej organizacji. Wiedza ta jest sumą wiedzy jawnej i cichej. Oba rodzaje są istotne dla sukcesu biznesowego.

Skupienie się na procesach innowacyjnych, które tworzą przewagę organizacji na rynku.

Skupienie się na ciągłych procesach usprawniania funkcjonowania organizacji, które w zasadniczy sposób są uzależnione od cichej wiedzy.

Skupienie się na procesach kształcenia, ponieważ wiedza, zarówno jawna jak i cicha, jest bezpośrednią ich konsekwencją.

Skupienie się na kompetencji kolektywnej (społecznej), czyli uzupełnianie się wiedzy różnych osób wewnątrz organizacji i jej części.

Rozwój myślenia systemowego: rozumienie relacji pomiędzy częścią i całością systemu, relacji wewnątrz systemu, wzorców zachowania się wewnątrz systemu oraz związków systemu z jego otoczeniem.

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 3

maj 2002

Cechy CMS: Zarządzanie konfiguracją

Celem zarządzania konfiguracją (treści, oprogramowania) jest planowanie, organizowanie, sterowanie i koordynowanie działań mających na celu identyfikację, przechowywanie i zmiany oprogramowania w trakcie jego rozwoju, integracji i przekazania do użycia. Każdy projekt musi podlegać konfiguracji oprogramowania. Ma ono krytyczny wpływ na jakość końcowego produktu. Jest niezbędne dla efektywnego rozwoju oprogramowania i jego późniejszej pielęgnacyjności.

Zarządzanie konfiguracją jest szczególnie ważne, jeżeli projekt może toczyć się przez wiele lat, jeżeli cel lub wymagania na oprogramowanie są niestabilne, jeżeli oprogramowanie może mieć wielu użytkowników, i/lub jeżeli oprogramowanie jest przewidziane na wiele platform sprzętowo-programowych.

W takich sytuacjach złe zarządzanie konfiguracją oprogramowania może całkowicie sparaliżować projekt lub doprowadzić do chaosu w zakresie ewidencji i organizacji treści.

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 4

maj 2002

Cechy CMS: integracja z istniejącymi aplikacjami

   Obecne systemy CMS muszą współdziałać z:  Popularnym oprogramowaniem: Word, Excell, Acrobat, PowerPoint, formaty graficzne, formaty multimedialne;  Mogą lub nawet powinny integrować oprogramowanie, które dotychczas działało w organizacji niezależnie od powstałego systemu CMS, np. systemem finansowo-ksiegowym, systemem bibliotecznym: Współdziałanie oznacza, że:  Praktycznie dowolne aplikacje mogą być wywołane w środowisku CMS  Rezultat tych aplikacji nie jest zakłócony przez to, że jednocześnie działa CMS  Rezultaty tych aplikacji są przejmowane przez CMS  Rezultaty są opakowane w kontekst HTML i przekazywane do klienta jako strony HTML.

W praktyce osiągnięcie takiej integracji nie jest łatwe,  szczególnie przy założeniu, że klient jest "chudy" i nie ma zainstalowanych odpowiednich programów.

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 5

maj 2002

Wizja architektury ICONS

Tekst Systemy biznesowej inteligencji Strony Web Integracja informacji Mapy wiedzy Bazy danych Modele semantyczne Pliki Sieci semantyczne Własności Wyszukiwanie Drzewa semantyczne koncepcyjne Sieci Mapy wiedzy Reprezentacja wiedzy Reprezentacja czasu Wnioskowanie Hiper-tekst Spadkowe systemy informacyjne Zarzadzanie dokumentami System zarządzania wiedzą Modele semantyczne XML RDF Grafy procesów Szyfrowanie Pliki Kontrola dostępu Bezpieczeństwo Podpis elektroniczny Forum dyskusyjne Repozytorium Zarządzanie wersjami Autentyfikacja Inżynieria wiedzy Współpraca HSM SZBD Zarządzanie procesami pracy Wymiana komunikatów Internet Intranet

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 6

maj 2002

Wstępna architektura prototypu ICONS

Poziom prezentacji wiedzy Strona XML/ DHTML Odwzorowanie obiektów informacyjnych (XSL, SVG) HTTP/ WebDav Serwer Definicja modelu treści (DTD, RDF) Rama zarządzania wiedzą Mapa wiedzy Odwzorowanie struktury treści Definicja reguł wnioskowania Odwzorowanie regyuł wnioskowania Silnik inferencyjny dyzjunktywnego Datalogu Poziom manipulacji wiedzą Baza treści (XML) Ekstrakcja i asocjacja wiedzy Baza ontologii (RDF) Zarządca hierarchicznej pamięci (Hierarchical Storage Manager, HSM) Wielo-formatowy mechanizm odwzorowania informacji Poziom integracji Istniejące heterogeniczne bazy danych

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 7

Systemy spadkowe Źródła informacji na WWW

maj 2002

Inna wizja architektury projektu ICONS

 Przedstawiona poprzednio architektura wydaje się zbyt eklektyczna i odzwierciedla bardziej stan obecnego chaosu w zakresie CMS niż docelową architekturę o logicznych i konsekwentnych założeniach.

Peryferia systemu

XML, RDF i inne technologie Web API oparte na obiektowym języku zapytań

a la

SQL Repozytorium aktywnej obiektowej bazy danych z dynamicznymi rolami obiektów Repozytorium metadanych zintegrowane z zarządzaniem konfiguracją

Peryferia systemu

Relacyjne bazy danych i inne spadkowe technologie K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 8

maj 2002

Architektura oparta na XML

Przeglądarka WWW

XML Narzędzia wspomagające XML : system autorski, itd.

Serwer Web Serwer aplikacji

Warstwa klienta Przeglądarka WWW

XML

Logiczna warstwa pośrednia

Interakcja z aplikacjami poprzez protokoły oparte na XML XML Baza danych w XML XML (strukturalizowana) XML Serwer integrujący XML, serwer zapytań, serwer hurtowni danych XML Translatory formatów z/do XML, pomosty

Zasoby danych

Obiektowo-relacyjna baza danych wspomagająca XML Obiektowa baza danych wspomagająca XML K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 9 Dokumenty XML na Webie Inne dokumenty na Webie: HTML Word,...

Zasoby danych pod OLE/DB

maj 2002

Architektura z modelem kanonicznym

HTML Użytkownik parametryzacja Program aplikacyjny API graficzne Moduł GUI język zapytań Procesor języka zapytań dla modelu kanonicznego API komunikacyjne Osłona dla bazy danych 1 API 1 Osłona dla XML/RDF XML/RDF API BD 1 K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 10 pliki XML/RDF inna osłona inne API inna BD/plik

maj 2002

Projektowanie Portalu Biznesowego

Tak może wyglądać portal....

Ale co dzieje się zanim on powstanie?

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 12

maj 2002

Definicja projektu portalu

 

Projekt portalu powinien być dobrze zdefiniowany zanim przystąpimy do jego realizacji.

Definicja projektu obejmuje  Analizę strategicznych uwarunkowań portalu w misji danej organizacji;  Nakłady niezbędne dla realizacji, wdrożenia i utrzymania portalu;  Realistyczny harmonogram realizacji i wdrożenia portalu;  Założenia odnośnie zawartości treściowej portalu;  Założenia odnośnie usług dostarczanych przez portal  Założenia odnośnie transakcji biznesowych realizowanych przez portal  Cel portalu z punktu widzenia biznesu, który będzie realizował;  Podstawowe, strategiczne wymagania w stosunku do portalu  Model biznesowy (biznes plan) zwrotu nakładów na stworzenie i utrzymanie portalu;  Analizę zagrożeń podczas realizacji i funkcjonowania portalu.

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 13

maj 2002

Studium osiągalności (1)

      Rozmiar projektu (w punktach funkcyjnych) w stosunku do rozmiaru zespołu projektowego, realizacyjnego i wdrożeniowego.

Dostępność podstawowych zasobów (budżet, ludzie, osobomiesiące) Ograniczenia czasowe (dostępność czasu, w przekroju poszczególnych zadań i etapów projektu).

Warunki wstępne niezbędne do realizacji projektu (aktywności lub inwestycje, które muszą być wykonane przed przystąpieniem do realizacji projektu).

Dostępność sprzętu i sieci do realizacji projektu i do działania portalu.

Dostępność oprogramowania na którym będzie zrealizowany i na którym będzie działał portal, dostępność narzędzi rozwoju oprogramowania (narzędzi CASE).

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 14

maj 2002

Studium osiągalności (2)

     Dostępność infrastruktury organizacyjnej i technicznej niezbędnej dla realizacji projektu (obsługa administracyjna, kadrowa, księgowa, zaopatrzeniowa, magazynowa, marketingowa, itd.) Dostępność infrastruktury organizacyjnej i technicznej niezbędnej dla funkcjonowania portalu; realistyczna ocena możliwości stworzenia takiej infrastruktury o ile ona nie istnieje.

Dostępność technologii i know-how.

Dostępność specjalistów wewnątrz organizacji tworzącej portal oraz zewnętrznych ekspertów (np. specjalistów grafików, programistów, stylistów, redaktorów, doradców, itd.) Dostępność zewnętrznych usług (outsourcing), kooperantów i dostawców.

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 15

maj 2002

Zarządzanie ryzykiem

    Na ryzyko projektu składają się wszystkie okoliczności, które mogą:  Spowodować opóźnienie realizacji portalu,  Zwiększenie kosztów tej realizacji,  Nie spełnienie oczekiwań klientów.

Wszystkie projekty są obarczone ryzykiem.

Zarządzanie ryzykiem polega na:  Zredukowaniu prawdopodobieństwa wystąpienia okoliczności zagrożeń,  Zminimalizowaniu skutków zagrożeń, które wystąpiły.

Aktywności niezbędne dla uniknięcia ryzyka:  Ciągłe śledzenie okoliczności, które mogą stać się zagrożeniami projektu,  Poprawianie planu celem zminimalizowania prawdopodobieństwa zagrożenia,  Określenie planu awaryjnego na wypadek okoliczności zagrożenia,  Wdrożenie planu w wypadku wystąpienia okoliczności zagrażającej.



Zarządzanie ryzykiem nigdy nie powinno zaczynać się od optymistycznego założenia „wszystko pójdzie dobrze” („jakoś to będzie”), ale raczej od pytania „co najprawdopodobniej może pójść źle?”. Nie jest to pesymizm, ale realizm.

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 16

maj 2002

Czynniki ryzyka (1)

 

Czynniki doświadczenia

 brak doświadczenia i/lub kwalifikacji kierownika projektu (niedoświadczony kierownik jest poważnym zagrożeniem dla projektu),  brak doświadczenia i/lub kwalifikacji personelu (personel powinien być sprawdzony pod względem kwalifikacji)  niedojrzałość dostawców (brak sukcesów w rozwijaniu podobnych projektów, brak standardów, brak certyfikatu ISO 9000, ...).

Czynniki planowania

 niedokładność metod szacowania czasu, kosztów, zasobów,  zbyt krótka skala czasowa (niemożliwość zrównoleglenia pewnych prac),  zbyt długa skala czasowa (zmiany wymagań, personelu, technologii),  zależność od awarii losowych, wandalizmu i sabotażu (zniszczenie sprzętu, zniszczenie danych, itd.),  zła lokalizacja personelu (utrudnienia w komunikacji),  zła definicja odpowiedzialności (brak odpowiedzialnych za kluczowe zadania, wykonywanie niepotrzebnych lub drugorzędnych zadań, ...),  częste zmiany personelu.

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 17

maj 2002

Czynniki ryzyka (2)

 

Czynniki technologiczne

 nowość technologiczna (brak doświadczeń, konieczność dodatkowego wysiłku na rozpoznanie, ...),  niedojrzałość lub nieodpowiedniość stosowanych metod (nowe metody są często niesprawdzone, konieczne jest praktyczne doświadczenie, ...),  niedojrzałość lub nieodpowiedniość narzędzi (personel powinien umieć je używać, mogą być nieodpowiednie w stosunku do metod, są zmieniane w trakcie projektu, ...),  niska jakość użytego komercyjnego oprogramowania (może być zawodne, słabo pielęgnowalne, niebezpieczne, nie stabilne, ...),

Czynniki zewnętrzne

 niska jakość lub niestabilność wymagań użytkownika,  słabo zdefiniowane, niestabilne lub niestandardowe interfejsy zewnętrzne,  niska jakość lub słaba dostępność systemów zewnętrznych (od których zależy powodzenie projektu; może być konieczne rozwijanie możliwości symulujących systemy zewnętrzne).

K.Subieta. Tworzenie portali biznesowych, Wykład 2, Folia 18

maj 2002