Studia Podyplomowe IT w Biznesie Wprowadzenie do handlu elektronicznego (HEL)

1. Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Studia Podyplomowe IT w BiznesieWprowadzenie do handlu elektronicznego(HEL) Wykład 3 Wykładowca: Prof. dr hab. inż. Kazimierz Subieta subieta@pjwstk.edu.pl http://www.ipipan.waw.pl/~subieta

2. Profesjonalny CMS do zarządzania tekstami w sklepie • System do edycji zawartości stron sklepu WYSIWYG (What you see is what you get) . • Edytor zainstalowany we wszystkich miejscach sklepu, w których można zmieniać teksty (opisy produktów, teksty informacyjne na stronie, newsy, newsletter itp.) • Bez znajomości html można dowolnie formować tekst w sklepie, podgląd zmienianych tekstów na bieżąco. • Rozbudowany system wprowadzania newsów tekstowych na stronie. • Podział newsów na grupy, możliwość umieszczania 1 newsa w kilku grupach lub np. tylko w 1 wersji językowej. • Newsy w formacie XML-RSS - RSS (Rich Site Summary) - publikowanie newsów w specjalnym, ujednoliconym formacie opartym na języku XML, które mogą być następnie pobierane i przechowywane przy pomocy tzw. czytników RSS.

3. Funkcje oprogramowania e-sklepu – Moduły dodatkowe (2) • Informacje - pozwala na dowolne tworzenie katalogów oraz informacji zawartych wewnątrz danego katalogu. • Wersja do druku - pozwala na wydruk ulotki o produkcie wraz ze zdjęciem, a także logiem i adresem sklepu internetowego sprzedawcy. • Cenniki w formacie PDF - pozwala na wydrukowanie aktualnej oferty wraz z cenami pochodzącymi z odpowiedniego dla danego klienta poziomu cenowego lub też zapisanie cennika jako pliku pdf. • TOP 10 - pozwala na wyświetlenie listy produktów najczęściej kupowanych lub oglądanych przez osoby dokonujące zakupów. • Zobacz też - umożliwia automatyczne bądź też ręczne tworzenie list produktów skojarzonych ze sobą i wyświetlanie ich klientom podczas dokonywania zakupów. • Upusty - automatycznie nalicza rabat według zadanych kryteriów i wyświetla użytkownikom informację zarówno o rabacie, jak i kwocie zamówienia uwzględniającej upust.

4. Funkcje oprogramowania e-sklepu – Zarządzanie bazą klientów • Możliwość przeglądania listy klientów • Zaawansowane wyszukiwanie klientów według następujących kryteriów: loginu, imienia, nazwiska, e-mail'a, daty • Dostęp do danych klienta (dane bilingowe i dane korespondencyjne) • Łatwa edycja danych klienta • Automatyczne nadawanie przez system numeru id klienta • Możliwość przypisania odpowiedniej liczby punktów klientowi • Możliwość zdefiniowania czy klient jest użytkownikiem hurtowym czy detalicznym • Wysyłanie maili do klienta z poziomu panelu administracyjnego • Dostęp do wszystkich transakcji dokonanych przez danego klienta • Informacja o dacie zarejestrowania się klienta • Usuwanie klientów • Lojalnościowy system punktów • Produkty polecane - Klienci którzy zakupili produkt x, zakupili również y.

5. Funkcje oprogramowania e-sklepu – Zarządzanie transakcjami (1) • Przeglądanie listy transakcji • Informacja o zamówionym towarze, numerze transakcji, danych bilingowych oraz danych dostawy • Możliwość zdefiniowania statusu zamówienia • Dostęp do danych klienta • Informacja o numerze IP, z którego zostało dokonane zamówienie • Informacja o formie płatności, dostawcy, koszcie zamówienia oraz dacie dokonania zamówienia • Możliwość wyświetlenia nie rozliczonych zamówień • Zaawansowane wyszukiwanie transakcji według następujących kryteriów: daty zawarcia transakcji, wartości transakcji, metody płatności, statusu transakcji, potwierdzenia płatności • Możliwość zdefiniowania ilości punktów za każde 100 PLN

6. Funkcje oprogramowania e-sklepu – Zarządzanie transakcjami (2) • Możliwość dodawania nowych statusów transakcji • Możliwość modyfikowania transakcji po otrzymaniu zamówienia. • Możliwość wprowadzania produktów niestandardowych (nie znajdujących się w cenniku). • Rozbudowane statusy transakcji: wysyłanie automatycznych potwierdzeń do klienta o statusie transakcji. • Klient ma wgląd w każdy etap realizacji zamówienia. • Rozbudowane wyszukiwanie i sortowanie transakcji. • Przypisanie danej transakcji do zdefiniowanego uprzednio partnera, jeśli transakcja nastąpiła po wejściu do sklepu ze strony partnera • Naliczanie prowizji dla partnerów. • Zestawienia dotyczące wybranego okresu. • Potwierdzanie transakcji partnera.

7. Funkcje oprogramowania e-sklepu – Magazyn produktów • Możliwość wprowadzenia stanów magazynowych dla wszystkich produktów. • Zmiana stanu magazynowego po dokonaniu/potwierdzeniu transakcji. • Wyszukiwanie produktów brakujących/na wyczerpaniu (powiadamianie e-mail). • Przechowalnia informacji o produktach, która stwarza możliwość przechowywania przez klienta w sklepie w swoim profilu towarów, których nie chce kupić w danym momencie, ale jest nimi zainteresowany i chce mieć możliwość szybkiego włożenia ich do koszyka bez ponownego wyszukiwania ich w sklepie.

8. Funkcje oprogramowania e-sklepu – System zarządzania dostawcami • możliwość obliczania kosztów dostawy na podstawie jednostki miary np. wagi, rozmiaru itp. • definiowanie listy krajów dostawy. • wybór kraju dostawy/strefy. • definiowanie zakresów jednostek miary i kosztów. • definiowanie indywidualnych dostawców dla różnych stref, nazwy dostawcy, krótkiego opisu oraz wartości zakupów powyżej, której dostawa jest bezpłatna • definiowanie metod płatności dla każdego z dostawców oddzielnie

9. Bezpieczeństwo • Główną zasadą jaką należy kierować się przy projektowaniu systemu jest zero tolerancji dla elementów mogących stwarzać zagrożenie - żadnych kompromisów zmniejszających bezpieczeństwo danych i serwisów. • Każda część programu powinna być dokładnie sprawdzana pod względem bezpieczeństwa. • Staramy się wyprzedzać potencjalnych "wrogów", testujemy nasze programy w warunkach zagrożenia, sami dokonujemy próbnych ataków. • Bezpieczeństwo oprogramowania opiera się na kilkustopniowej strukturze, kilku warstwach ochronnych, które skutecznie bronią dostępu do danych klientów. Dodatkowo program powinien korzystać z niewykrywalnego monitoringu, który analizuje i rejestruje osoby pracujące z programem. • Ważne dane powinny być szyfrowane i nikt, nawet administrator serwera, nie może mieć do nich dostępu. • Dane osobowe powinny być przechowywane zgodnie z wymogami ustawy o ochronie danych osobowych.

10. Baza danych - konkretny przypadek EMPiK • Koncepcja bazy danych opiera się na następujących kryteriach: • Elastyczność przy wprowadzaniu nowych kategorii produktów. Aplikacje nie powinny podlegać radykalnym zmianom w wyniku zmian własności obecnego asortymentu sprzedawanych produktów, jak również w wyniku pojawiania się nowych kategorii produktów. Przykładowo, mogą się pojawić nowe kategorie PLAKAT lub MAPA, którą trzeba będzie dostawić do już oprogramowanych produktów. • Elastyczność przy wprowadzaniu opisów nowych własności istniejących produktów. Przykładowo, kamery cyfrowe mogą zostać wyposażone w oprogramowanie, którego typ stanie się istotną cechą handlową. • Skuteczna automatyczna kontrola wprowadzanych danych: słownikowa, typologiczna, i/lub referencyjna. • Precyzyjne odwzorowanie ról osób związanych z wytworzeniem danego produktu: autorów, wykonawców, kompozytorów, dyrygentów, aktorów, solistów, redaktorów, edytorów, scenarzystów, fotografików, operatorów, itd. • Być może istotne okaże odwzorowanie organizacji związanych z wytworzeniem danego produktu: orkiestr, zespołów rockowych, domów wydawniczych, itd.

11. Proponowana realizacja modelu pojęciowego • Konieczne jest stworzenie struktur w bazie danych umożliwiających objęcie hierarchii wszystkich kategorii produktów oraz elastyczność w zakresie dostawiania nowych kategorii w trakcie eksploatacji systemu. • Dotychczasowa struktura była oparta na założeniu, że każda nowa kategoria produktów jest zapisana w postaci tabeli w relacyjnej bazie danych. • Ze strategicznego punktu widzenia takie założenie jest naiwne, gdyż może spowodować eksplozje ilości tabel i ich atrybutów, co w konsekwencji musi zaowocować niejednorodnościami i błędami.

12. Kategorie produktów (1) • Przykład sprzętu fotograficznego pokazuje, że liczba kategorii, które mogą być przedmiotem informacji handlowej dla klienta, jest znaczna. • Kategorie są objęte hierarchiczną strukturą o nieznanej liczbie pięter. • Najwygodniej zaimplementować wszystkie kategorie jako strukturę danych o hierarchicznej budowie. Hierarchiczna organizacja kategorii CATEGORY parent CATEGORY_ID CATEGORY_NAME * 1+ belongs_to * PRODUCT PRODUCT_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE

13. Kategorie produktów (2) • Produkt może należeć do więcej niż jednej kategorii. • Podstawowymi kategoriami produktów są książki, multimedia, filmy, muzyka, sprzęt foto, kosmetyki, komputery, ale nie będą one reprezentowane jako odrębne tabele. • Każda kategoria będzie opisywana przez identyfikator i nazwę. • Kategoria może mieć dowolną liczbę pod-kategorii (związek parent). • Każdy produkt będzie należał (związek belongs_to) do jednej kategorii, przy czym przyjmuje się założenie implicite, że jeżeli produkt należy do kategorii A, to automatycznie należy do wszystkich kategorii nadrzędnych w stosunku do A. • Np. jeżeli produkt należy do kategorii „Filtr korekcyjny 49”, to automatycznie należy także do kategorii „Filtr korekcyjny”, „Filtr”, „Akcesoria” i „Sprzęt foto”. Rysunek na następnym slajdzie przedstawia fragment hierarchii kategorii. Linie łączące kategorie są związkami „parent”.

14. Przykład hierarchii kategorii produktów

15. Informacja o produktach • Każdy produkt będzie opisywany przez atrybuty przedstawione poniżej: PICTURE PIC_ID PRODUCT PIC_FORMAT PIC_FILE * PRODUCT_ID PRODUCT_NAME consists_of * * SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL has VAT SWW_CODE(?) BARCODE has AVAIL_DATE designed * EASYNET_NAME(?) INPUT_DATE LAST_UPDATE 0..1 PRODUCT_GROUP 0..1 MODEL_ID COMPLEX_PRODUCT MODEL_NAME MODEL_DESCR MAIN_IN_BUNCH MIN_SEL_PRICE MAX_SEL_PRICE

16. Opis założeń • Każdy produkt może mieć dowolną liczbę zdjęć (klasa PICTURE). Zdjęcie jest częścią w agregacie związanym z produktem lub grupą produktów. Zdjęcie nie może w związku z tym istnieć samodzielnie. • Produkt jest opisywany przez następujące atrybuty: • AVAIL_DATE - określa kiedy produkt będzie fizycznie dostępny w sklepie, • INPUT_DATE - określa datę wprowadzenia informacji o produkcie do bazy danych (i co za tym idzie, może być podstawą informacji o nowościach), • LAST_UPDATE, który określa datę ostatniej aktualizacji. • Produkty mogą być złożone, tj. powiązane w kilka produktów. Złożone produkty mogą się pojawić w wyniku promocji, która wiąże sprzedaż kilku produktów lub oferuje pewne produkty za darmo, o ile były zakupione inne produkty. Przyjmuje się, ze produkt złożony jest odrębnym obiektem COMPLEX_PRODUCT, który ma własne atrybuty, takie jak cena, zdjęcia, itd. W szczególności, cena produktu złożonego nie musi być sumą cen składowych, zaś niektóre atrybuty mogą być nierelewantne, np. VAT, który może być różny dla produktów składowych. • Hierarchię produktu złożonego wyznacza związek consists_of. Atrybut MAIN_IN_BUNCH jest identyfikatorem produktu składowego, który jest główny w produkcie złożonym.

17. Atrybuty produktu • Każda kategoria produktu może mieć własne atrybuty, które powinny być obsługiwane przez aplikację. • Zapis tych atrybutów w postaci tabel spowodowałby eksplozję ich ilości, zwiększenie skłonności do błędów oraz zwiększenie narzutów na pielęgnację. • Dodatkowa trudność polega na tym, ze niektóre atrybuty (np. autor w przypadku kategorii książka) mają charakter powtarzalny (wielu autorów), opcjonalny (brak autora) i/lub złożony (autor może być złożoną hierarchiczną strukturą). • Te okoliczności sugerują filozofię opisu produktu zbliżoną do XML. Zastosowanie XML jako podstawy zapisu informacji o atrybutach produktu (w postaci jednego XML-owego stringu) przypisanego do produktu jest kontrowersyjne z kilku powodów, np. z powodu słabych możliwości kontroli słownikowej i referencyjnej, słabych możliwości aktualizacji, i innych niedogodności. • Z tego powodu opis atrybutów został związanych z klasą kategorii atrybutów. Jest to przedstawione na następnym slajdzie.

18. Atrybuty kategorii produktów • Każda kategoria jest związana z pewną liczbą atrybutów. • Klasa ATTRIBUTE może być zaimplementowana w postaci tabeli w relacyjnej bazie danych. Informacja DICTIONARY CHECK ustala czy atrybut podlega kontroli słownikowej, informacja REPEATED, ustala czy atrybut może mieć dla danego produktu wiele wartości, informacja binarna OPTIONAL ustala, czy atrybut może być nieobecny w opisie produktu. • Każda kategoria może być podłączona do wielu atrybutów i odwrotnie, jeden atrybut może charakteryzować wiele kategorii. Dziedziczenie atrybutów: jeżeli dany atrybut jest właściwy dla kategorii A, to jest on także właściwy dla wszystkich podkategorii kategorii A, w dół hierarchii kategorii. • Ten sposób zapisu jest także właściwy dla ról osób, które mogą być charakteryzowane przez atrybuty takie jak: „autor”, „wykonawca”, „kompozytor”, „dyrygent”, „aktor”, itd. • Istotne jest tu oddzielenie ról osób od samych osób, gdyż w tym ujęciu ta sama osoba może być w danym produkcie (lub w różnych produktach) np. aktorem, reżyserem, piosenkarzem i reżyserem.

19. Produkty, kategorie i atrybuty ATTRIBUTE ATTRIBUTE_ID ATTRIBUTE_NAME ATTRIBUTE_TYPE DICTIONARY_CHECK REPEATED OPTIONAL * can_be_described_by * CATEGORY parent CATEGORY_ID CATEGORY_NAME * 1+ belongs_to * PRODUCT PRODUCT_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE

20. Atrybuty i kategorie CATEGORY CATEGORY parent 1 3 "książki" "filmy" CATEGORY 35 can be described by "filmy z ograniczeniem wieku" can be described by can be described by can be described by can be described by can be described by can be described by ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATT_ID: "a74" ATT_ID: "a44" ATT_ID: "a1" ATT_ID: "a4" ATT_ID: "a87" ATT_NAME: "słowo kluczowe" ATT_NAME: "tytuł" ATT_NAME: "reżyser" ATT_NAME: "aktor" ATT_NAME: "dozwolony od lat" TYPE: " string " TYPE: " string " TYPE: " string " TYPE: " string " TYPE: " unsigned " DICT_CHECK: YES DICT_CHECK: NO DICT_CHECK: YES DICT_CHECK: YES DICT_CHECK: NO REPEATED: YES REPEATED: NO REPEATED: NO REPEATED: YES REPEATED: NO OPTIONAL: YES OPTIONAL: NO OPTIONAL: YES OPTIONAL: YES OPTIONAL: NO

21. Wartości atrybutów • Każdy produkt jest charakteryzowany przez pewną liczbę wartości atrybutów. Z jednej strony, wartości te będą podłączone do klasy ATTRIBUTE, zaś z drugiej strony – do klasy PRODUCT . Tabeli powinno być tyle, ile typów wartości. Przewiduje się wartości atrybutów będące identyfikatorami agregatów. • Dla każdego takiego agregatu powinna istnieć odrębna tabela lub zespół tabel. Realizacja tej sytuacji, z uwzględnieniem trzech typów i dwóch agregatów PERSON i TRACK jest przedstawiona na poniższym rysunku. Podany sposób zapisu klas PERSON i TRACK jest jednocześnie realizacją kontroli słownikowej i referencyjnej, ponieważ minimalizuje ryzyko pojawienia się np. tego samego nazwiska w wielu miejscach w różnej pisowni.

22. Wartości atrybutów ATTRIBUTE ATTRIBUTE_ID ATTRIBUTE_NAME ATTRIBUTE_TYPE DICTIONARY_CHECK is a value of REPEATED OPTIONAL * can_be_described_by * Attribute value * * CATEGORY parent CATEGORY_ID CATEGORY_NAME * 1+ belongs_to describes * PRODUCT PRODUCT_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE

23. Kolejna faza tworzenia diagramu klas DICTIONARY DICT_NAME is_pattern_for ATTRIBUTE * ATTRIBUTE_ID ATTRIBUTE_NAME ATTRIBUTE_TYPE DICTIONARY_CHECK STRING_DICT INT_DICT DATE_DICT PERSON_DICT TRACK_DICT REPEATED OPTIONAL * * * * * STRING_DICT_ITEM DATE_DICT_ITEM PERSON TRACK VALUE VALUE PERSON_ID TRACK_ID LAST_NAME(S) VOLUME_NO * FIRST_NAME(S) TRACK_NO NICK_NAME(S) TITLE INT_DICT_ITEM NATIONALITY TIME VALUE .....other attributes if necessary DESCRIPTION * checks AUDIO_CLIP AU_ID can_be_described_by AU_FORMAT AU_FILE checks * is_value_of ATTRIBUTE_VALUE describes * CATEGORY parent CATEGORY_ID PRODUCT CATEGORY_NAME * PRODUCT_ID * PRODUCT_NAME 1+ SELL_PRICE ATTR_VALUE_INT ATTR_VALUE_PERSON BUY_PRICE INT_VALUE STORE_STATE IS_AVAIL * VAT belongs_to SWW_CODE(?) BARCODE ATTR_VALUE_STRING ATTR_VALUE_DATE ATTR_VALUE_TRACK AVAIL_DATE STRING_VALUE DATE_VALUE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE

24. Kontrola słownikowa • Podany wyżej sposób jest także odpowiedni dla kontroli słownikowej. Możliwe są tu dwie sytuacje: • utworzenie wielu słowników, dla kontroli poszczególnych atrybutów, • zintegrowany słownik dla kontroli wszystkich atrybutów. • Pierwsza wersja jest lepsza z punktu widzenia administracji i zarządzania, • Druga jest bardziej uniwersalna. W tym zakresie można byłoby wypracować pewien kompromis. Na rysunku przedstawiona jest wersja pierwsza, bez rozwijania poszczególnych kategorii słowników.

25. Całość modelu pojęciowego bazy danych DICTIONARY 0..1 DICT_NAME is_pattern_for * ATTRIBUTE ATTRIBUTE_ID ATTRIBUTE_NAME ATTRIBUTE_TYPE DICTIONARY_CHECK STRING_DICT INT_DICT DATE_DICT PERSON_DICT TRACK_DICT REPEATED OPTIONAL * * * * * STRING_DICT_ITEM DATE_DICT_ITEM PERSON TRACK VALUE VALUE PERSON_ID TRACK_ID LAST_NAME(S) VOLUME_NO * FIRST_NAME(S) TRACK_NO NICK_NAME(S) TITLE INT_DICT_ITEM NATIONALITY TIME VALUE .....other attributes if necessary DESCRIPTION * checks AUDIO_CLIP can_be_described_by AU_ID AU_FORMAT AU_FILE checks * is_value_of * ATTRIBUTE_VALUE describes * CATEGORY parent CATEGORY_ID CATEGORY_NAME * * 1+ ATTR_VALUE_INT ATTR_VALUE_PERSON INT_VALUE * ATTR_VALUE_STRING ATTR_VALUE_DATE ATTR_VALUE_TRACK STRING_VALUE DATE_VALUE SUPPLIER * has supplies * belongs_to SUPPLIER_ID * * SUPPLIER_NAME PICTURE PIC_ID * PRODUCT PIC_FORMAT * PIC_FILE ADDRESS PRODUCT_ID PRODUCT_NAME POSTAL_CODE * * SELL_PRICE LOCALITY BUY_PRICE ADDRESS_STRING STORE_STATE IS_AVAIL consists_of has * VAT SWW_CODE(?) BARCODE has AVAIL_DATE designed * EASYNET_NAME(?) produces INPUT_DATE LAST_UPDATE 0..1 PRODUCT_GROUP 0..1 PRODUCER MODEL_ID 0..1 COMPLEX_PRODUCT MODEL_NAME PRODUCER_ID MODEL_DESCR MAIN_IN_BUNCH PRODUCER_NAME MIN_SEL_PRICE MAX_SEL_PRICE

26. Podsumowanie • Handel elektroniczny na świecie przestał już być kosztownym eksperymentem, promowanym przez grupę zapaleńców. • 4% ogólnej wartości sprzedaży i rynek wart 66 mld $ w USA w 2004 r. jest tego najlepszym dowodem. • W Polsce pomimo pewnych słabości i barier handel elektroniczny to branża, która rozwija się bardzo dynamicznie i ma ogromny potencjał na dalszy, intensywny rozwój. • 171% średniorocznego wzrostu, przez ostatnie 4 lata, oraz 1 mld PLN obrotu nie pozostawiają złudzeń. • Co trzeci nabywca, który już kupuje w sieci, deklaruje, że zamierza w najbliższej przyszłości wydawać więcej niż dotychczas. • Oprogramowanie sklepu internetowego wymaga profesjonalnego podejścia, zarówno od strony zastosowanego narzędzia, stworzonego na jego bazie oprogramowania sklepu, jaki i wdrożonych procesów działania takiego sklepu