Model ofertowy Model ofertowy w Katalogu realizowany jest w oparciu o model SID. Wykorzystanie tego modelu umożliwia:

Transkrypt

1 Więcej o Katalogu Produktów możesz przeczytać tutaj. (pdf do otwarcia i ściągnięcia) Model ofertowy Model ofertowy w Katalogu realizowany jest w oparciu o model SID. Wykorzystanie tego modelu umożliwia: Szczegółową konfigurację ofert z ustaleniem cen, upustów oraz zależności produktówych i ofertowych Wariantową budowę ofert Określanie czasu życia oferty Profilowanie ofert pod kątem różnych segmentów rynku Profilowanie ofert w zależności od lokalizacji Elastyczny sposób rozbudowywania oferty Funkcjonalność ofertowa wsparta jest intuicyjnym, elastycznym, graficznym interfejsem użytkownika, który umożliwia: Szybką i prostą konfigurację nowej oferty "od zera" bądź na podstawie innej oferty Szybką i łatwą modyfikację istniejących ofert Przejrzysty podgląd zawartości oferty Prosty sposób ustalenia zależności produktowych w ramach oferty Łatwe zarządzanie ceną i upustem w ramach oferty

2 Dodatkowo tworzenie oferty w Centralnym Katalogu Produktów Nexio wsparte jest: Wielowymiarowym przypisywaniem cen Symulacjami produktowymi Zarządzanie finansowe poprzez implementację współczynników zyskowności takich jak NPV, ROI, IRR, itp. Architektura rozwiązania Centralny Katalog Produktów zrealizowany jest jako niezależny komponent, pod względem architektonicznym cechuje się następującymi elementami: mapowanie produktów CRM na produkty SID dekompozycja produktów SID na usługi CFS, RFS oraz zasoby fizyczne przekazywanie zależności pomiędzy usługami Oddzielne instancje katalogów na jednej instancji aplikacji np. katalogi wielu firm Architektura zapewniająca bardzo wysoką dostępność aplikacji (Skalowanie pionowe i poziome) Rozgłos, synchronizacja, replikacja katalogu. Tam gdzie mamy wiele fizycznych instancji i tam gdzie inne systemy w architekturze klienta przechowują lokalną kopię. Katalog Produktów składa się z następujących komponentów: Interfejs DB Interfejs Java API Zakres funkcjonalny komponentów Najważniejsze funkcjonalności Katalogu Produktów, które odpowiedzialne są za mapowanie produktów CRM oraz dekompozycję produktów SID zaimplementowane zostały po stronie Interfejsu DB. W komponencie Java API nie ma logiki związanej z mapowaniem oraz dekompozycją. Komponent ten odpowiada tylko za odczytanie danych z bazy, za pomocą odpowiedniego API SQL. Na podstawie danych pobranych z bazy generowane są produkty, usługi oraz zasoby fizyczne wraz z charakterystykami. Komponent Java API odpowiada również za obsługę komunikacji pomiędzy systemami zewnętrznymi. Interfejs DB Interfejs DB realizuje następujące funkcjonalności: utrzymywanie statycznej struktury produktów oraz dekompozycji na warstwę Customer Facing Service (CFS), Resource Facing Service (RFS) oraz Resource utrzymywanie zalezności pomiędzy usługami utrzymywanie statycznej struktury mapowań atrybutów z systemu CRM na produkty Katalogu wersjonowanie zmian w strukturze produktów oraz mapowań udostępnianie API do wprowadzania zmian w strukturze produktów oraz mapowań udostępnianie API na potrzeby mapowania produktów CRM na produkty SID udostępnianie API na potrzeby dekompozycji produktów SID na usługi CFS, RFS oraz zasoby zewnętrzne przekazywanie zależności pomiędzy usługami w kontekście zlecenia na dekompozycję Interfejs Java API Interfejs Java API odpowiada za realizację następujących funkcjonalności: obsługa żadań z systemów zewnętrznych pobieranie danych z bazy po przemapowaniu produktów CRM na produkty SID

3 pobieranie danych z bazy po dekompozycji produktów SID na usługi CFS, RFS oraz zasoby fizyczne budowanie obiektów SID wraz z charakterystykami generowanie odpowiedzi do systemów zewnętrznych Podejście do dekompozycji produktów Identyfikacja produktów oraz dekompozycja ich na usługi zrealizowana została w oparciu o model SID. Wyodrębnione zostały następujące grupy produktów: Dostęp do Internetu Usługa telefoniczna Telewizja Urządzenie Hosting Usługi złożone Usługi multimedialne Usługi wspierające Każdy z w/w produktów zdekomponowany został na wartstwę usług CFS oraz RFS w sposób zapewniający jak najwyższy poziom modularności. Modularność w dekomponowaniu produktów na usługi CFS określana była na podstawie usług tak jak są postrzegane oraz rozumiane przez Klienta. W przypadku dekompozycji warstwy CFS na RFS modularność usług określana była na podstawie usług realizowanych przez warstwę sieciową. Model SID pozwala na dekompozycję usług implementacyjnych (RFS) na zasoby fizyczne (Physical Resource) oraz zasoby logiczne (Logical Resource). Produkt może zostać zdekomponowany na usługę CFS oraz zasób fizyczny (Physical Resource). Model SID nie pozwala na dekompozycję usług CFS bezpośrednio na zasoby. Dekompozycja taka musi zostać zrealizowana tylko z uwzględnieniem warstwy usług RFS. Dekompozycja produktów na usługi CFS Model SID definiuje usługi (Service), jako implementacje produktów oferowanych za pomocą mechanizmu ofertowego ProductOffering. Obiekt Product, jest mechanizmem pozwalającym na zgrupowanie kompatybilnych usług i zaprezentowanie ich wygodnym i zrozumiałym zestawieniem dla rynku (klienta). Dla przykładu, Szybki Internet, może być zestawieniem usług typu stacjonarnego dostępu do Internetu, konta oraz oprogramowania antywirusowego, itd. Parametryzacja szablonu produktów (ProductSpecification) powinna być tworzona tak, aby jednoznacznie można było określić jakie składowe usługi stanowią daną instancję produktu. Dekompozycja usług CFS na RFS Model SID rozróżnia usługi na dwa typy: klienckie (CFS) i implementacyjne (RFS). Usługi klienckie to te, które są składową oferty rynkowej, a klient jest świadom ich zakupu. Usługi implementacyjne RFS to takie, które technicznie realizują usługi CFS za pomocą odpowiednio skonfigurowanych zasobów (Resource). Usługi implementacyjne RFS nie są bezpośrednio udostępniane klientom za pomocą produktów, do tego celu służą usługi klienckie CFS. Usługi RFS reprezentują technologiczny potencjał warstwy sieci lub innych platform usługowych na świadczenie usług. Usługi RFS komponowane są w sposób, który pozwala na obsługę atomowych usług (np. service), a zarazem w sposób pozwalający na komponowanie złożonych usług RFS (np. pakietów) lub usług CFS (np. Internet routing i CPE AutoConfiguration dla produktów Internetowych). Podejście do zaprojektowania katalogu jest oparte o analizę świadczonych usług od strony sieci (zasobów) i od strony oferowanych produktów. Rezultatem jest lista re-używalnych usług RFS, które mogą wchodzić w skład wielu usług CFS, a których ścieżka realizacji pozostaje niezmienna. Dla zachowania przejrzystości struktury katalogu i spójności dekopozycji pomiędzy usługami, wprowadzony został podział, który odzwierciedla powyższy opis. Dla przykładu rozdzielony został

4 dostep do sieci od dostępu do Internetu. Taki model oferuje wyższy poziom modularności i pozwala na reużywanie planu realizacji dla atomowych usług RFS za pomocą systemu Order Manager. Poniższy diagram ilustruje opisaną koncepcję. Rys. 1 Koncepcja dekompozycji usług CFS na RFS Składowe techniczne (wiele wariantów technologicznych) Internet Access Usługi RFS i CFS przekład na rzeczywistość Kompleksowe sieciowe usługi korporacyjne Jedna MPLS IP VPN (ADSL Based Access) IP Network Access LastMile External vendor usługa CPE CPE Management nexio for business Orange Internet BSA ADSL IP LLU ADSL IP VPN MPLS IP VPN OnNet ADSL 19 Rysunek nie przedstawia dekompozycji żadnego konkretnego produktu, stanowi tylko przykład podejścia do dekompozycji usług. Dekompozycja CFS na składowe RFS będzie bezpośrednio wynikać z kombinacji wartości cech (parametrów) CFS. W zależności od tych wartości jeden CFS może dekomponować się na wiele

5 kombinacji usług RFS. Dla przykładu usługa (stacjonarnego) szerokopasmowego dostępu do Internetu, w zależności od przypisanych wartości cech może być zrealizowana za pomocą różnych technologi (tu usług RFS), gdzie każda będzie posiadała unikalną ścieżkę realizacji. Parametryzacja została dobrana tak, aby jednoznacznie wyznaczyć listę RFS'ów, a zarazem nie wymuszać skomplikowanej technicznej parametryzacji usług CFS. Pakietowanie produktów Model SID pozwala na pakietyzowanie produktów, co może być umotywowane zależnością technologiczną lub ofertową pomiędzy produktamii. Zależności technologiczne mogą mieć bezpośrednią reprezentację na poziomie usług, co z kolei będzie miało wpływ na proces realizacji. Jako przykład może posłużyć pakiet produktowy VOIP, który składa się z produktów usług telefonicznych i Internetowych. Usługi telefoniczne, świadczone w technologii Internetowej (VoIP) wymagają dostępu do Internetu, natomiast sam dostęp do Internetu będzie wymagał adekwatnej konfiguracji tak, aby obsłużyć ruch głosowy na odpowiednim poziomie. Pakietyzacja produkowa umożliwi odpowiednią dekompozycję na składowe usługi i określenie zależności pomiędzy ich planami realizacji. Poniższy diagram ilustruje opisaną koncepcję. Rys. 2 Pakietowanie produktów Wersjonowanie konfiguracji systemu W Katalogu Produktów zaimplementowany został mechanizm wersjonowania zmian uwzględniający możliwość zdefiniowania konfiguracji: obowiązujących w określonych przedziałach czasu stanowiących wersję stanu konfiguracji Zrealizowane zostanie to poprzez znacznik czasu oraz katalog wersji.

6 Znacznik czasu Znacznik czasu pozwala na definiowanie konfiguracji, która powinna obowiązywać w określonych przedziałach czasu. Katalog wersji Katalog wersji umożliwia przełączenie stanu konfiguracji pomiędzy różnymi wersjami. Wprowadzanie kolejnych zmian nie nadpisuje dotychczasowych konfiguracji. Zmiany nanoszone są na katalog nowoutworzony. API do wprowadzania zmian w katalogu Przygotowany został zbiór metod umożliwiających wykonywanie następujących operacji na danych, które przechowywane będą w bazie danych Katalogu Produktów: definiowanie produktów, usług, atrybutów oraz relacji pomiędzy nimi definiowanie mapowań usług oraz atrybutów definiowanie mapowań atrybutów CRM na produkty w Katalogu walidacja spójności danych wersjonowanie zmian w Katalogu archiwizacja modyfikowanych danych Metody umożliwiają zarządzanie danymi w Katalogu, tak by nie było konieczności wprowadzania zmian innymi metodami niż w/w. Wymagania sprzętowo-programowe Poniżej przedstawiamy wymagania sprzętowe oraz aplikacyjne gwarantujące prawidłowe działanie Katalogu Produktów. Wymagania sprzętowe Wymagania sprzętowe dla Katalogu Produktów są następujące: Moduł Zasób Parametry Dysk 20 GB Interfejs DB RAM 16 GB CPU 2 Dysk 10 GB Interfejs Java API RAM 16 GB CPU 2 x (2,5-3)GHz 64bit Wymagania programowe Wymagania programowe dla Katalogu Produktów są następujące: Moduł Aplikacja Wersja Interfejs DB Baza danych Oracle 11g Interfejs Java API JDK Java w wersji wyższej od 1.5 Serwer aplikacji jboss od do 6.1.0(rekomendowana)