Tworzenie Portali Biznesowych

Tworzenie Portali Biznesowych

Wykład 2

Systemy zarządzania treścią (cd.)

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

Warszawa

Wykładowca:dr hab. inż. Kazimierz Subieta profesor PJWSTK

[email protected]://www.ipipan.waw.pl/~subieta

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

Cechy CMS: zarządzanie wiedzą

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żą.

knowledge management


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.


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.


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.


Wizja architektury ICONS

Systemzarządzania

wiedzą

Repozytorium

Wyszukiwanie

Współpraca

Bezpieczeństwo

Integracjainformacji

Reprezentacjawiedzy

Systemybiznesowejinteligencji

Bazydanych

Strony Web Pliki

Zarzadzaniedokumentami

Spadkowesystemy

informacyjne

Szyfrowanie

Kontrola dostępu

Autentyfikacja

Podpis elektroniczny

Zarządzanieprocesami pracy

InternetIntranet

Wymianakomunikatów

Forumdyskusyjne

XML RDF

Pliki

HSM SZBD

Zarządzaniewersjami

Hiper-tekst

Grafyprocesów

Drzewakoncepcyjne

Mapy wiedzy

Tekst

Własności

Inżynieriawiedzy

Siecisemantyczne

Mapy wiedzy

Modele semantyczne

Siecisemantyczne

Modele semantyczne

Wnioskowanie

Reprezentacjaczasu


Poziomprezentacji

wiedzy

Poziommanipulacji

wiedzą

Poziomintegracji

Istniejące heterogeniczne bazy danych Systemy spadkowe Źródła informacji na WWW

Wielo-formatowy mechanizm odwzorowania informacji

Baza treści(XML)

Baza ontologii(RDF)Ekstrakcja i

asocjacjawiedzy

Zarządca hierarchicznej pamięci (Hierarchical Storage Manager, HSM)

Ramazarządzania

wiedzą

Silnik inferencyjnydyzjunktywnego Datalogu

Odwzorowanie obiektów informacyjnych(XSL, SVG)

Odwzorowanie regyuł wnioskowaniaOdwzorowanie struktury treści

Strona XML/DHTML

Definicja modelu treści

(DTD, RDF)Mapa wiedzy Definicja reguł

wnioskowania

HTTP/WebDavSerwer

Wstępna architektura prototypu 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.

API oparte na obiektowym języku zapytań a la SQL

Repozytorium metadanych zintegrowane

z zarządzaniem konfiguracją

XML,RDFi innetechnologieWeb

Relacyjnebazy

danychi inne

spadkowe technologie

Peryferiasystemu

Peryferiasystemu

Repozytorium aktywnej obiektowej bazy danych z

dynamicznymi rolami obiektów

Inna wizja architektury projektu ICONS


Logiczna warstwa pośrednia

Zasoby danych

Warstwa klienta

XML

XML XML

PrzeglądarkaWWW

PrzeglądarkaWWW

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

Serwer WebSerwer aplikacji

Baza danych w XML (strukturalizowana)

Interakcja z aplikacjami poprzezprotokoły oparte na XML

Obiektowo-relacyjna baza danych

wspomagająca XML

Obiektowa baza danych

wspomagająca XML

Zasoby danychpod OLE/DB

Innedokumenty na Webie: HTML

Word,...

Innedokumenty na Webie: HTML

Word,...

Dokumenty XML

na Webie

Dokumenty XML

na Webie

Serwer integrujący XML, serwer zapytań,

serwer hurtowni danych

Translatory formatów z/do XML, pomosty

XML XML XML

Architektura oparta na XML


Moduł GUI parametryzacja

język zapytań

API komunikacyjne

Osłona dla bazy danych 1

BD 1

API 1

inna osłona

inna BD/plik

Osłona dla XML/RDF

pliki XML/RDF

XML/RDF API

API graficzne

Użytkownik Program aplikacyjny

Procesor języka zapytańdla modelu kanonicznego

inne API

Architektura z modelem kanonicznym

HTML

Projektowanie Portalu Biznesowego


Tak może wyglądać portal....Ale co dzieje się zanim on powstanie?


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.


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).


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.


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.


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.


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).

Documents

Tworzenie Portali Biznesowych