Zrób Sobie Firmę

Jednym z kilku wyzwań koncepcyjnych, jakie World WideWeb stawia społeczności baz danych, jest kwestia logiki zapytań. Zdecydowanie dominującym paradygmatem w dzisiejszej architekturze baz danych jest relacyjna baza danych z jej dobrze znanym modelem tabelarycznym, podmiotami i relacjami. Przyjęcie tego frameworka w naturalny sposób dało początek specyficznemu podejściu do przeprowadzania zapytań o dane, w szczególności rozwinięciu Simple Query Language (SQL). SQL jest zależny od danych znajdujących się, przynajmniej koncepcyjnie, w wierszach i kolumnach w jednej lub kilku tabelach. Zapytania są tworzone w odniesieniu do nich: „znajdź wszystkich klientów w Indiach zamawiających zapasy o wartości przekraczającej 1 milion USD”, można łatwo przedstawić w ten sposób. Jednak wiele danych on-lineWeb nie jest zestawionych w formie tabel. Zapytania są zwykle oparte na ciągach, wyszukując na przykład „Indie”, być może wzbogacone o operatory logiczne: w ten sposób „Indie” ORAZ „komputer”. Jest to prosty, brudny i dość skuteczny sposób na zebranie obszernego ładunku informacji, ale także odzyskanie wielu, które nie są szczególnie istotne. Próbując zintegrować „czyste” bazy danych z „brudnymi” danymi sieciowymi, musimy żądać kompromisu z obu stron. To już się dzieje. W przypadku baz danych rośnie świadomość, że indeksowanie zawartości jest ważne: streszczenia zawartości tworzone są automatycznie i można je przeszukiwać za pomocą łańcuchów logicznych. Po stronie internetowej coraz częściej praktykowane jest pojawianie się stosunkowo znormalizowanych metadanych opisujących zawartość stron internetowych. Omówimy te aspekty dalej, gdy przyjrzymy się ekstrakcji wiedzy. Wcześniej w tym rozdziale omówiliśmy XML jako sposób mapowania między dokumentami handlowymi współpracujących organizacji. W szczególności zwróciliśmy uwagę, że organizacje często mają różne poglądy na temat niezbędnych pól na fakturach, formularzach zamówień itp. Nie jest to charakterystyczne dla handlu internetowego; jest to również problem w przypadku łączenia baz danych zaprojektowanych przez różne zespoły. Ogólnie rzecz biorąc, ten problem z danymi jest bardziej złożony niż przypadek handlowy. Metadane przechowywane w bazach są często określane jako służące dwóm celom: administracyjnym i biznesowym. Metadane administracyjne dotyczą sposobu zarządzania danymi: kiedy zostały/ma być, zaktualizowane, czy zostały oczyszczone, ich źródło i tak dalej. Metadane biznesowe opisują, czym są dane: ich związek z pewnym procesem biznesowym, zasady, według których są uzyskiwane z innych pozycji („zysk” ¼ „dochód” – „koszt”) i tak dalej. Przy tworzeniu systemu wymiany danych konieczne jest uwzględnienie zarówno rodzajów informacji metadanych, jak i reguł konwersji między metadanymi dla różnych baz danych. Należy zapewnić narzędzia umożliwiające osobom niebędącym ekspertami tworzenie tych mapowań.

Chociaż w najlepszym z możliwych światów projektowanie systemów informatycznych dla przedsiębiorstw powinno zaczynać się od odgórnego określenia, czym chcemy zarządzać, a następnie integracji śrub i nakrętek, które to zapewnią, prawie nigdy nie zaczynamy od tak korzystnego punkt widzenia: dziedzictwo i liczne inicjatywy w ramach zainteresowanych organizacji zwykle to uniemożliwiają. W związku z tym należy wykonać dość dużo pracy, po prostu łącząc to, co już istnieje. Zazwyczaj zasoby danych organizacji znajdują się w wielu miejscach, w różnych formatach

Pozycja pokazana na rysunku przedstawia realia wielu organizacji. Często stanowią one pole bitwy między zintegrowaną, ale być może nie reagującą lub biurokratyczną kontrolą sprawowaną przez dział IS firmy, a nowszymi, fragmentarycznymi inicjatywami podejmowanymi przez poszczególne jednostki funkcjonalne, które szybciej tworzyły własne data marty. W tę i tak już zagmatwaną scenę został wrzucony korporacyjny Intranet, który ma zapewnić każdemu w organizacji bezpośredni dostęp online do wiedzy korporacyjnej. W takich sytuacjach oczekiwania tych osób są czasami bardzo zawiedzione, gdy powiedziano im, że jedynym sposobem, w jaki można uzyskać dostęp do plików z jednego systemu przez inny, jest fizyczny transport taśm lub dysków z danymi. To nie wszystko, często dane muszą być następnie uruchamiane przez programy konwertujące w trybie off-line, których opracowanie zajmuje trochę czasu i może zapewnić tylko bardzo ograniczone okna na dane, ze względu na różnice w modelach danych. Nawet jeśli fizyczny transport można zastąpić często drogi i wciąż raczej powolny, masowy transfer plików drogą elektroniczną (rysunek 2.9), przy użyciu takich metod, jak Internet File Transfer Protocol (FTP), integracja aplikacji nie jest łatwa do uzyskania na różnych platformach. Ponadto dane nie są statyczne.

Zmienia się, a zmiany te muszą być zsynchronizowane we wszystkich aplikacjach składających się na proces biznesowy. Transfer plików między procesami nie musiałby zatem odbywać się tylko raz, ale za każdym razem, gdy odpowiednie dane uległyby zmianie. To szybko staje się niemożliwe do opanowania. Zamiast tego dane powinny być utrzymywane tylko na platformie hosta i tylko odpowiednie ich części są pobierane przez zależne procesy znajdujące się w innych systemach, gdy jest to wymagane. Aby to osiągnąć, jednym podejściem jest zastosowanie zasad komponentów, jak opisano we wcześniejszej dyskusji o architekturze

Komponenty, które są interfejsem między dwoma systemami, muszą być zdolne do utrzymania niezawodnej komunikacji poprzez interfejs, być może z pełną integralnością przetwarzania transakcji, zaangażowaniem i wycofaniem. W praktyce zarządzanie tym może odbywać się za pomocą oddzielnego pakietu oprogramowania uruchomionego na osobnym serwerze. Podstawowym wymogiem jest to, że struktura danych jednej bazy danych musi być odwzorowana na strukturę drugiej: typowym przykładem tego jest konwersja wartości jednostkowych – wagi funtów na kilogramy, dolarów amerykańskich na franki francuskie itp. – które mogą wystąpić w przypadku budowania przedsiębiorstw wielonarodowych. Innym powszechnym przykładem są tabele danych relacyjnych baz danych: niektóre mogą używać jednej kolumny zawierającej adres i kod pocztowy, podczas gdy inne, które przyjęły marketing kodu pocztowego, mogą podzielić adres i kod na dwie oddzielne kolumny. Oczywiście zaletą jest tworzenie rozwiązania (komponentowego lub innego), które dostarcza programistom zestaw narzędzi, które w prosty sposób pozwalają na konstruowanie reguł przeprowadzania takich konwersji. Obecnie istnieje szereg rozwiązań komercyjnych. Zobacz na przykład Hummingbird’s Genio Suite. Oczywiście pojawiają się problemy z wydajnością, gdy uruchamiamy aplikacje, które mogą wymagać nie tylko złożonych zapytań o dane, ale nawet bardziej złożonych i czasochłonnych procesów pośredniczących, które mogą być uruchamiane na danych. Jednym z rozwiązań jest zapewnienie hierarchicznego zestawu procesów, z prostymi wywoływanymi do prostych zadań i delegowanie jak największej ilości pracy do istniejących silników baz danych, które są zoptymalizowane pod kątem własnych danych. W przypadku bardziej złożonej wymiany danych wymiana może być prowadzona przez program zarządzający, działający na osobnym serwerze. Ponadto, gdy bazy danych znajdują się na tym samym serwerze lub są bezpośrednio połączone przez bramę komunikacyjną, czasami możliwe jest umożliwienie im bezpośredniej komunikacji, zmniejszając w ten sposób potrzebę „puzonowania” strumienia danych od źródła do serwera zarządzającego do miejsca docelowego.

Dobre organizacje gromadzą dane w celu prowadzenia działalności, ale także do przyszłych analiz, aby kierować ich strategią. Logiczna (nie fizyczna) integracja tych danych w pojedynczą, zarządzalną przestrzeń informacyjną, zwłaszcza tam, gdzie ma to na celu wspieranie podejmowania decyzji zarządczych, nazywana jest hurtownią danych. Hurtownia danych to podejście koncepcyjne, a nie rzecz fizyczna, której celem jest integracja wielu rzeczywistych baz danych, które mogą być montowane na heterogenicznym zbiorze platform sprzętowych i programowych, zwykle rozproszonych. W poprzednim rozdziale omówiliśmy ogólny przypadek technicznej integracji takich systemów, odnosząc się do architektur komponentów i potrzeby interpretacji między bazami danych, od niskopoziomowych formatów danych po wysokopoziomową semantykę danych. Omówimy tutaj głównie technologie oparte na aplikacjach, które leżą na nich. Projektując hurtownię danych, należy podjąć decyzję, czy ma ona być zorientowana na dane, czy na aplikacje. W pierwszym przypadku model danych dla hurtowni jest zaprojektowany (w miarę możliwości) tak, aby był niezależny od poszczególnych aplikacji. Raczej stara się być wystarczająco wszechstronna, aby objąć istniejące i prawdopodobne przyszłe zastosowania. Dostosowanie do potrzeb dowolnej konkretnej aplikacji lub użytkownika jest zapewniane przez oprogramowanie do obsługi zapytań i prezentacji

Na rysunku jest to dolna warstwa danych, która jest pierwsza, z z niego generowane są widoki zorientowane na aplikację. To holistyczne podejście jest często niewykonalne dla organizacji, które rozwinęły obsługę danych w sposób zdecentralizowany. Częściej rozwiązanie będzie zorientowane na aplikację (lub kilka rozwiązań zorientowanych na aplikacje). Rozwiązanie magazynowe opiera się wówczas na integracji wielu baz danych, które obsługują jedną jednostkę funkcjonalną, na przykład marketing. Jak pokazano na rysunku

dane często występują w postaci tabel w relacyjnych bazach danych. Ze względów historycznych są to często różne roczniki i wzornictwo. Hurtownia aplikacji rozwiązuje skromniejszy problem integracji tych danych w coś, co można przeszukiwać w jednorodny sposób, bez przeprojektowywania podstawowego modelu danych. Nomenklatura jest dość nieprecyzyjnie zdefiniowana, ale hurtownie aplikacji są zwykle większymi i bardziej ambitnymi przykładami data martów, które powstają z nowych lub istniejących baz danych i są przeznaczone do obsługi stosunkowo zwartych procesów biznesowych, takich jak zarządzanie klientami. Bardzo realne niebezpieczeństwo pojawia się, gdy składnice danych nakładają się na dane, które zawierają. Utrzymanie i integralność stają się poważnym problemem i wiele czasu może zająć rozwiązywanie sporów między działami finansowymi i marketingowymi, na przykład, jeśli każdy ma dostęp do innego zestawu danych dotyczących sprzedaży i algorytmów obliczania marży. Niemniej jednak wiele organizacji wybiera tę drogę ze względu na trudności i opóźnienia związane z uzyskaniem zgody kierownictwa na rozwiązanie globalne [64]. Chociaż celem projektowania hurtowni może być stworzenie ogólnego rozwiązania, które jest niezależne od poszczególnych aplikacji, główną cechą takiego systemu musi być to, że jest on zorientowany na biznes, a nie po prostu ogromne repozytorium danych. W szczególności powinien być dostosowany do modelu procesu, a nie tradycyjnego modelu danych [65]. Jednym z powodów, dla których jest to ważne, jest wydajność. Zapytania dotyczące tradycyjnej, jednoprzedmiotowej bazy danych, używanej do obsługi pojedynczej operacji, mogą stosunkowo łatwo przeniknąć dane w sposób optymalizujący wydajność – modelarz danych wie, które są dominującymi jednostkami i atrybutami, i może odpowiednio zaprojektować bazę danych. Jednak tam, gdzie hurtownia ma obsługiwać kilku „masterów”, ich zapytania trafią do bazy z kierunków, których niekoniecznie można było przewidzieć. W związku z tym zwyczaj i praktyka bazy danych mogą wymagać modyfikacji. Na przykład normalizacja, zasada projektowa, zgodnie z którą wpisy nie powinny pojawiać się częściej niż to konieczne, często musi być zaniechana w interesie szybkości [66]. Ponadto, chociaż warto zachować centralną, ogólną koncepcję magazynu, może być konieczne tworzenie podzbiorów danych na lokalnych serwerach, dostosowanych do potrzeb konkretnych jednostek biznesowych. Oprogramowanie magazynowe będzie w tym przypadku zawierało mechanizmy synchronizacji tych lokalnych baz danych z systemem nadrzędnym, z regularną aktualizacją i oznaczaniem danych ze szczegółami ostatniej aktualizacji.

Przypuśćmy, że jesteśmy w stanie zdefiniować, uchwycić i przeanalizować pokaźny zbiór dokładnej „wiedzy korporacyjnej”. Co z tym zrobimy? W szczególności, kto powinien mieć do niego dostęp, być może nawet z możliwością interakcji w celu opisania go lub zmiany? Tradycyjny model dostępu do danych korporacyjnych był dość restrykcyjny: działy finansowe miały dostęp do danych finansowych, działy marketingu do danych marketingowych i tak dalej. Częściowo powodem było to, że bazy danych były oddzielne i skonfigurowane tylko do obsługi procesów jednostki funkcjonalnej, która je ustawiała; część tego stanowiła trudność w zapewnieniu wygodnego i bezpiecznego dostępu do nich z odległych miejsc. Wielowymiarowa prezentacja danych i możliwości transmisyjne firmowych intranetów zmieniły to wszystko. Teoretycznie każdy, kto ma prawa dostępu do danych, powinien mieć możliwość ich przeglądania, być może nawet dostosowanego do ich modelu biznesowego, a nie do modelu biznesowego. Czasami te prawa dostępu mogą zostać rozszerzone poza samą firmę, na partnerów, dostawców, a nawet klientów. Niektóre firmy, ostrożnie lub w inny sposób, eksperymentują obecnie z takim podejściem do uwalniania wiedzy w postaci portalu korporacyjnego. Zasadniczo chodzi o kierowanie wieloma procesami skoncentrowanymi na wiedzy w firmie, które bezpośrednio lub pośrednio wchodzą w interakcję z ludźmi za pośrednictwem zestawu interfejsów internetowych, z których każdy ma zestaw praw dostępu do jednego, spójnego zbioru danych przedsiębiorstwa. Jeśli jest to możliwe, można uzyskać pewne wyraźne korzyści, w tym:

† Zarówno publiczne, jak i prywatne aspekty firmy opierają się na tym samym modelu informacyjnym. Poglądy klientów i wewnątrz przedsiębiorstwa nie są zatem niespójne, a jeśli różnią się szczegółami i wiedzą, istnieje jasne wyjaśnienie, dlaczego tak się dzieje.

† Dane klienta i wewnętrzne dane procesu są takie same. Gdy klient śledzi niedostarczenie zamówienia, agent pomocy i dyspozytor, którego pytają, będą pracować z tą samą ścieżką audytu. Wszystkie będą działać z tymi samymi nagłówkami cen i szczegółów dotyczących zamawiania zapasów (chociaż oczywiście mogą istnieć dane „warunków specjalnych” połączone z pełną integralnością referencyjną i widoczne tylko dla przedstawicieli firmy).

† Działy marketingu i projektowania będą miały dostęp do komentarzy klientów na temat produktów firmy. Wady produktów, sugestie nowych funkcjonalności, porównania z innymi produktami można pracować wspólnie, dzieląc się wspólną wiedzą i postrzeganiem.

† Jednostki funkcjonalne i zespoły ds. planowania wykonawczego będą miały wspólny pogląd semantyczny dotyczący możliwych do zarządzania elementów organizacji: „region” sprzedaży lub geograficzny będzie konsekwentnie definiowany, a dyskusje na temat wyników i targetowania mogą być prowadzone sprawnie i bez nieporozumień.

Zwróć uwagę, jak klient stał się częścią zespołu wiedzy. Jednym z kluczowych elementów budowania e-biznesu będzie zdolność do czerpania korzyści z danych klientów on-line. Sieć daje znacznie większą moc gromadzenia wzorców zachowań on-line, które demonstrują upodobania i awersje do produktów. Należy rozważyć, jak najlepiej zintegrować te informacje z dowolnym firmowym magazynem danych. Oczywiście należy unikać opierania tego głównie na wprowadzaniu wiadomości e-mail, ponieważ jest to trudne do przekonwertowania na automatyczne wprowadzanie. Możliwe są ankiety on-line, wiele informacji można też uzyskać, projektując formularze, które można wypełnić przez callcenter agentów i przenoszone do dostępnej bazy danych.

Niezależnie od tempa pełnej standaryzacji pionowej XML zdarzają się DTD (niezależnie od tego, czy na przykład wszyscy zgadzają się co do standardowego sposobu opisu produktu), bez wątpienia przed technologią w zakresie ogólnej obsługi transakcji handlowych, szczególnie w połączeniu z językami programowania, takimi jak Java, czeka bardzo pozytywna przyszłość. Formularze zamówień on-line to prosty przykład: najprostszym sposobem zaprogramowania formularza zamówienia on-line jest stworzenie formularza HTML, który umożliwia klientowi wpisanie danych i przesłanie ich na serwer WWW. Niestety, jak zauważyliśmy w innym miejscu, podczas wprowadzania danych do systemu generowany jest wysoki stopień błędu, który może sięgać nawet 20% w przypadku formularza wielowierszowego. Nie ma łatwego i niedrogiego sposobu na naprawienie tego, co prowadzi do niezadowolenia klientów i utraty interesów. Zamiast tego coraz częściej rozwiązaniem jest wysyłanie formularza do terminala klienta z osadzonym fragmentem kodu wykonywalnego do sprawdzania formularzy (np. aplet Java), który działa na komputerze klienta i sprawdza wprowadzone dane z szablonem. XML zapewnia doskonały sposób kodowania tego szablonu. Jest w języku, który jest stosunkowo łatwy do zrozumienia; może być generowany niezależnie od kodu Java i udostępniany kodowi i koderowi, gdy jest to wymagane; może być rozwijany wokół procesu biznesowego, a nie aplikacji sprawdzającej formularz klienta; można go zsynchronizować ze zmianami w procesie biznesowym, zapewniając integralność. Ponadto jest to sposób na szerokie publikowanie w Internecie zasad handlowych organizacji. Te procesy handlowe XML mogą być łatwo dostępne przez zdalnych inteligentnych agentów, aby umożliwić w pełni zautomatyzowane przetargi, współpracę itp., jak opisano wcześniej. Nawet tam, gdzie różne organizacje stosują różne opisy XML swoich reguł handlowych, ustrukturyzowana i jasno zdefiniowana dyscyplina kodowania procesu może w wielu przypadkach umożliwić tworzenie mapowań między nimi, umożliwiając w ten sposób handel.

Zwykłym sposobem przesyłania danych internetowych między hostami online jest obecnie HTML. Problem z HTML polega na tym, że chodzi głównie o wygląd informacji, a nie o to, co one „oznaczają”. Możemy używać terminów „tytuł”, „autor”, „data publikacji”, „kod ISNB” itp., ale nie mają one specjalnego znaczenia w HTML. Dlatego nie można ich łatwo wybrać automatycznie w większym tekście; nie można też sprawdzić poprawności ciągu, który one reprezentują. Nie możemy na przykład łatwo sprawdzić, czy podana wartość ISBN (np. 0-471-98794-8) składa się z zestawu pól zawierających tylko liczby, oddzielonych myślnikami. Ten brak HTML został w dużej mierze naprawiony w rozwoju Extensible Mark-up Language (XML). XML nadal zapewnia mechanizm układu i wyglądu tekstu, podobnie jak HTML, ale jest znacznie silniejszy w swojej zdolności do nadawania jakiejś formy „znaczenia” wybranym terminom w tekście, a wybór ten jest w dużej mierze w gestii autora . Weźmy przykład z naszej dyskusji o tym, jak opisać konkretną książkę (Networked Futures): chcemy określić, że ma tytuł, autora, wydawcę, identyfikator ISBN, datę i opis. Następnie uproszczony opis XML jest pokazany poniżej

<items> w nawiasach to są tagi. W przedstawionych przykładach każdy z nich reprezentuje typ danych. Informacje istotne dla konkretnego typu tagu to te zawarte między parą <items> i </items> (Użytkownicy HTML będą dobrze zaznajomieni z tą notacją.) W przykładzie widzimy, że istnieje globalny element o nazwie <book> w którym zagnieżdżonych jest wiele innych tagów: <title>, <author>, itd. Pokazaliśmy tylko jedną warstwę zagnieżdżania, ale XML pozwala nam to rozszerzyć w dowolnym stopniu. Na przykład możemy sobie wyobrazić, że tytuł. składał się z dwóch części:

i tak dalej. Korzyść z automatycznego przetwarzania powinna być jasna: ponieważ znaczniki są zdefiniowane i zawierają ciągi danych, programowi znacznie łatwiej jest „zrozumieć”, że „Networked Futures” jest tytułem, a nie autorem lub fragmentem wolnego -opis tekstowy, oczywiście pod warunkiem, że jest świadomy sposobu, w jaki definiujemy książkę i terminów związanych z tą definicją. Jak osiąga się ten ostatni warunek? Musimy upublicznić naszą definicję „książki”. Możemy to zrobić w XML na wiele sposobów, z których jednym jest nagłówek naszego przykładu powyżej z odniesieniem do definicji typu dokumentu (DTD). To kolejny dokument, który zawiera ogólny szablon „książki” i opcjonalnie dodatkowe zasady ułatwiające sprawdzenie poprawności danych. DTD można zlokalizować poprzez jego adres URL. Zakłada się, że strony handlowe, a nawet organizacje międzynarodowe, takie jak organizacje handlowe, mogłyby umieścić swoje DTD i inne dokumenty XML w Internecie, aby handel mógł odbywać się bez dwuznaczności i błędów. W rzeczywistości XML to znacznie więcej, niż przed chwilą omówiliśmy. W szczególności wiele działań dotyczy definiowania, w jaki sposób XML powinien reprezentować prezentację danych w dokumentach elektronicznych, co oczywiście jest przedmiotem zainteresowania projektantów stron internetowych w eCommerce. Jednak to, co omówiliśmy, jest prawdopodobnie najbardziej znaczącym wpływem, jaki XML wywrze na rozwój elektronicznego biznesu: jego potencjał umożliwiający tworzenie standardowych modeli biznesowych dla transakcji automatycznych. Jak dotąd jest to tylko potencjał; siła napędowa musi pochodzić od modelu do technologii, a modele muszą być tworzone w drodze porozumienia. Jak to się stanie, nie jest jeszcze jasne: czy będzie pochodzić od stowarzyszeń branżowych, współpracy opartej na technologii, takiej jak World Wide Web Consortium, czy od dominujących dostawców oprogramowania? Czy zostanie to osiągnięte w sektorach wertykalnych (np. EPICS i ONIX współpracują nad mapowaniem między ich modelem a XML), czy za pomocą międzysektorowych ogólnych definicji handlowych („faktura”, „odwołanie” itp.)? Rzeczywiście, może się zdarzyć, że niektóre wiodące na rynku przedsiębiorstwa podążą za wczesnym modelem EDI i opracują własne modele handlowe. Chociaż w pewnym sensie może to być szkoda, nie będzie to miało tak wyniszczającego efektu, jak to samo podejście dwadzieścia lat temu. Zastrzeżony EDI tworzył blokadę we wszystkich warstwach procesu, od poziomu bajtów w górę. Tworzenie strategii migracji z własnych definicji XML do wspólnego standardu powinno być łatwiejsze. Ale to nie będzie trywialne. Jeszcze przez jakiś czas przedsiębiorstwa będą musiały ostrożnie stąpać po tym obszarze.

Pomimo ostrzeżeń podanych powyżej, nie ma wątpliwości, że internetowy handel EDI szybko stanie się wszechobecny w całej społeczności handlowej. Jak już powiedzieliśmy, usługi TCP/IP i Internet zapewnią znacznie łatwiejsze środowisko transmisji dla transakcji międzyfirmowych. Widzieliśmy, jak oprogramowanie pośredniczące oparte na komponentach pozwala nam łączyć klientów i serwery w wielowarstwowe architektury dowolnie złożonych procesów. Interoperacyjność baz danych w Internecie stała się rzeczywistością. Co z jednostkami danych i modelami biznesowymi, które je napędzają? Co musimy zrobić, aby znacznie łatwiej osiągnąć interoperacyjność międzybranżową? Na rysunku podajemy bardzo stylizowaną i uproszczoną fakturę, która może przechodzić między dwiema firmami.

Aby mógł on zostać przetworzony automatycznie, należy stworzyć i narzucić pewne specyfikacje i ograniczenia. Po pierwsze, dokładnie tak jak w przykładzie księgowym, musimy zdefiniować różne elementy składające się na tę transakcję. Musimy zarezerwować zestaw nazw odpowiadający różnym częściom formularza: „faktura”, „od” (który prawdopodobnie jest obiektem zwanym „dostawca”) itp. Muszą one zostać umieszczone w internetowej bibliotece dozwolonych terminów i terminologii. Prawdopodobnie musimy zdefiniować i rozgraniczyć cały zestaw elementów, które są wymagane do wystawienia prawidłowo sformułowanej faktury – w podanym przykładzie można się spierać, że nie ma wątpliwości, czy cena odnosi się do kosztu jednostkowego lub koszt dwóch sztuk. Musimy również ustawić ograniczenia dotyczące używanych zestawów znaków, dozwolonej liczby znaków, być może symboli specjalnych, takich jak £ lub $ i tak dalej. Jeszcze jedno: faktura jest podpisana podpisem cyfrowym, który prawdopodobnie zawiera dane uwierzytelniające firmy wystawiającej oraz funkcję skrót, która zapewnia, że ​​dane nie zostały naruszone. Oprócz określenia wszystkich wcześniej wspomnianych ograniczeń, musi istnieć jakiś sposób na opisanie, w jaki sposób ta sygnatura ma być wyprowadzona i sprawdzona. Podsumowując, nasz proces EDI musi:

† Jeżeli transakcja dotyczy ludzi, upewnij się, że można ją zaprezentować na wszystkich prawdopodobnych platformach prezentacyjnych.

† W przestrzeni wspólnej dla wszystkich zaangażowanych stron zdefiniuj terminologię transakcji.

† Ustaw limity wartości, które może mieć każdy z terminów.

† Prawdopodobnie sprawdź ich zgodność, on-line, w czasie rzeczywistym i uruchom procedurę obsługi wyjątków, aby rozwiązać wszelkie problemy.

† Zdefiniuj i wykonaj procedury w celu zakończenia innych aspektów transakcji.

Musimy więc przesyłać dane między stronami zaangażowanymi w transakcję, wraz ze standardowymi szablonami, które kontrolują jej integralność, prezentację i które mogą aktywować wymagane procesy.

Europejska Grupa ds. Handlu Elektronicznego w Sektorach Książek i Serii (EDItEUR) jest główną organizacją europejską zajmującą się koordynacją, rozwojem, promocją i wdrażaniem EDI w sektorach książek i wydawnictw seryjnych (np. czasopism i magazynów). . W styczniu 2000 r. stworzyli wersję 3.02 słownika danych EPICS, która zasadniczo reprezentuje ich definicję produktów typu „książka”. Bez Wstępu, zajmuje siedemdziesiąt jeden stron A4! Książka nie jest oczywiście tak prosta, jak mogłoby się na pierwszy rzut oka wydawać. Aby w pełni zrozumieć, dlaczego tak się dzieje, prawdopodobnie konieczne jest przeczytanie całego dokumentu, ale można uzyskać pewne zrozumienie, przyglądając się pokrótce jednemu z dwóch aspektów i przykładów. Dokument EPICS opisuje na wielu poziomach elementy danych, które są związane z opublikowanymi produktami. Na najwyższym poziomie EPICS definiuje (jak dotąd) pięć obiektów: „Produkty – nieseryjne” (np. „książki”), „Prace”, „Komponenty produktu”, „Seria” i „Czasopisma”. Poniżej tego poziomu znajdują się kompozyty, które z kolei składają się z poszczególnych elementów danych. Na przykład książka (która jest przykładem „produktu nieseryjnego”), nazwana „Networked Futures” autorstwa WS Whyte, może być częściowo opisana, jak pokazano na rysunku

Jest to przedstawione w schemacie EPICS (w przybliżeniu, ponieważ mamy nieco uproszczone rzeczy) w następujący sposób w tabeli

Przykład obiektu: „Produkt nieseryjny” (w tym przypadku książka)

Przykład pola w obiekcie: C030 „tytuł”, wartość = futures w sieci C040 „autorstwo” wartość = Whyte WS

Przykłady kompozytów: C010 „identyfikator obiektu”

Przykłady pól w złożonym: 0001 „przestrzeń nazw”, wartość = 02 (ISBN) 0003 „identyfikator przestrzeni nazw” = 0-471-98794-8

Litery i cyfry (np. C010) odnoszą się do ich kodów identyfikacyjnych w spisie danych. Jak wspomniano, jest to przybliżona reprezentacja: na przykład pozycje takie jak tytuł i autorstwo zwykle nie są podawane bezpośrednio jako wartości, jak pokazano w Tabeli 2.1. Normalnie byłyby sformatowane pod kątem elementów danych, czyli komponentów niezłożonych. Element tytułu (kod C180) będzie zawierać kwalifikator elementu tytułu i wartość. C180 element tytułu:

0608 kwalifikator = 03 (co oznacza, że ​​następujący tekst będzie tekstem tytułu)

0605 element = sieciowe kontrakty terminowe

Katalog danych jest obszerny: definiuje sposoby reprezentacji danych wydawcy, szczegóły dotyczące pozyskiwania, języki, zaangażowane regiony geograficzne; obejmuje nawet możliwość opisania nagród, jeśli w ogóle, wygranych przez produkt. Choć może to być obszerne, EPICS nie jest jedynym rozwiązaniem pełnego opisu terminu „książka”. Powody, dla których nie jest, są różne i być może przynajmniej tak polityczne, jak racjonalne: czy EPICS ma „prawo” do określenia książki? Co się stanie, jeśli inna organizacja ma inny pogląd? Na przykład EPICS jest europejskim; Amerykańskie Stowarzyszenie Wydawców (AAP) oddzielnie rozpoczęło tworzenie „standardowego” opisu, zwanego ONIX. Jest to nieco prostszy opis i dotyczy wyłącznie terminów amerykańskich. Jednym z przykładów różnic między EPICS i ONIX jest to, że ten ostatni zajmuje się wyłącznie wymiarami imperialnymi – rozmiarami w calach, a nie milimetrach, wagami w uncjach, a nie gramach. Kolejną różnicą, która ma charakter polityczny, jest fakt, że AAP nie jest organem normalizacyjnym, a niektórzy uważają, że nie do nich należy próba ustanowienia standardu! (Tak czy inaczej, zachęcające jest to, że EPICS i ONIX wydają się współpracować w celu stworzenia „uniwersalnego” standardu ONIX, który harmonizuje oba schematy). Nawet rozwiązanie definicji „książki” nie jest tak naprawdę wystarczające do opisania całkowicie i jednoznacznie proces handlu w sektorze księgarskim. W grę wchodzą inne kwestie, na przykład zarządzanie prawami. Tutaj również trwają prace nad opracowaniem modelu. Obejmuje to interesujące podejście do problemu pod kątem trójkątnych ustaleń między rzeczami (treścią), transakcją i zaangażowanymi osobami (rysunek 2.4). Relacje między tymi podmiotami są następnie opisywane przez relacje werbalne: „ludzie piszą/sprzedają/kupują/wynajmują” itd., a pełniejsze definicje bytów i relacji są w trakcie opracowywania. To wszystko może być bardzo nudne dla zapalonego przedsiębiorcy eCommerce: nic z tego nie jest nowe i na pewno odzwierciedla po prostu wcześniej nieudane próby wprowadzenia rozwiązań EDI jako uniwersalnego mechanizmu handlowego? Wierzyć, że to byłoby złe. To prawda, że ​​niektóre niepowodzenia EDI były związane z kosztami transmisji, złożonością protokołów i szeregiem innych problemów z niską warstwą. Ale z drugiej strony w przypadkach, w których EDI odniosło sukces, było to w dużej mierze spowodowane prawidłowym modelem biznesowym. Ten problem pozostanie bez względu na to, czy nowa technologia zostanie przywołana. Bez poważnego zastanowienia się nad modelem biznesowym i właściwymi definicjami obiektów danych i metod procesów, zwolennicy internetowego EDI są narażeni na poważne niebezpieczeństwo tworzenia ślepych uliczek i znacznych kosztów awarii. Kolejna opowieść ostrzegawcza: w naszym opisie struktury usługi EDI (Rysunek 2.1) pokazaliśmy również zestaw „usług” – rozwiązywanie problemów ad hoc, bezpieczeństwo, oznaczanie datą, ścieżka audytu i tak dalej. W przeszłości, dzięki EDI opartemu na VAS, funkcje te były zapewniane przez dostawcę VAS. Transakcje międzybranżowe opierają się na ograniczonym, a nie doskonałym zaufaniu. W przypadkach spornych zawsze odwoływano się do ścieżki audytu strony trzeciej, na przykład weryfikując czas i datę przesłania transakcji, „Nowoczesny” EDI ma nadzieję, że pozbędzie się pośrednika strony trzeciej, aby obniżyć koszty i ogólnie wprowadzić większą elastyczność. To niewątpliwie może, ale praktycy muszą pamiętać, aby uwzględnić mechanizmy zastępujące te inne usługi o wartości dodanej, a nie tylko zajmować się technicznymi kwestiami przetwarzania danych.

Tam, gdzie osoby lub organizacje chcą się ze sobą komunikować, muszą dzielić wspólny język i zestawy protokołów, aby uniknąć zamieszania i błędów. Od kilkudziesięciu lat uświadamiano sobie, że pojawienie się komputerów i telekomunikacyjnych łączy danych otworzyło drogę do automatyzacji transakcji biznesowych jako sposobu na ich przyspieszenie i zmniejszenie ich błędów, ale tylko wtedy, gdy ten język i protokół istnieją. Metody, które to osiągają, są określane zbiorczo jako elektroniczna wymiana danych lub EDI. EDI to tak naprawdę kompletny proces biznesowy, a nie tylko technologia. Przez lata szereg standardowych podejść w zakresie uzgodnionej definicji procesu, formatów danych i sieci komunikacyjnych zostało rozwiniętych do stanu, który był stosunkowo dojrzały na długo przed tym, jak Internet i sieć stały się wszechobecne. EDI odniosło sukces, ale nie przytłaczająco: jedno ze źródeł twierdzi, że zaledwie 10 000 firm w USA korzysta obecnie z EDI [62]. Problemem był jeden z protokołów własnościowych i konieczność tworzenia umów wymiany międzyzakładowej. Nowoczesne postępy mogą zmniejszyć niektóre trudności, choć nie wszystkie. Dzisiejsze wyzwanie polega na przekształceniu lekcji wyniesionych z „staromodnego” EDI na ich odpowiedniki w środowisku internetowym. Ile zachować, a ile wyrzucić, to wielkie pytanie. Załóżmy, że organizacja A chce używać EDI do prowadzenia interesów z organizacją B. Na przykład, A może chcieć zamówić towary od B w ramach umowy call-off. Jak pokazano na Rysunku , aby to osiągnąć, wymagane są liczne rozważania i działania na różnych poziomach.

Niektóre części są oczywiste. Na najbardziej podstawowym poziomie musimy stworzyć niezawodną metodę przesyłania danych z jednego komputera na drugi. W przeszłości często osiągano to poprzez łączenie się z siecią prywatną oferowaną przez zewnętrznego dostawcę usług o wartości dodanej (VAS), zwykle firmę telekomunikacyjną lub sieciową (np. AT&Tor IBM). Obecnie i coraz częściej w przyszłości te prywatne sieci zostaną zastąpione publicznymi usługami internetowymi opartymi na protokole TCP/IP i protokołach aplikacyjnych. Szybko zanika potrzeba omawiania standardów transmisji, czy to bezpośrednio między zaangażowanymi firmami, czy za pośrednictwem dostawcy VAS. Musimy również hermetyzować („opakować”) nasze dane z dodatkowymi informacjami, aby umożliwić jednej bazie danych prawidłowe działanie na danych z innej. Na najprostszym poziomie jest to problem z formatowaniem. Na przykład niektóre bazy danych mogą używać znaków ASCII, niektóre binarne. Duża część lukratywnego biznesu dostawców VAS w przeszłości polegała na prostej konwersji kodu ze starych schematów kodowania na bardziej nowoczesne. Ale co z danymi? Co to dokładnie oznacza? Firma X wie, jakie potrzeby chce pominąć; tak samo firma Y i oboje dokładnie wiedzą, co z nią zrobić i jak dopasować ją do swoich procesów biznesowych. Oboje są przekonani, że ich model danych i procesów jest jedynym właściwym dla wykonywanego zadania. Problem polega na tym, że w większości przypadków ich definicje danych różnią się, podobnie jak ich procesy, ponieważ zostały zaprojektowane w izolacji, aby spełnić ich własne postrzegane wymagania. Spójrz na rysunek 2.2, który pokazuje prosty przykład zestawów produktów dwóch firm, X i Y.

Firma Y sprzedaje produkty na rynku konsumenckim. Produkty te zbudowane są z podzespołów montowanych w skrzyni. Pokazano dwa przykłady: Model A1 to jednostka podstawowa, która składa się z obudowy mieszczącej cztery „standardowe” wsuwane podzespoły. Model AB1 to produkt luksusowy, z jednym z wsuwanych podzespołów (B21) zbudowanym według „lepszego” standardu. Pierwotnie firma Y budowała wszystkie podzespoły obu tych produktów we własnym zakresie. W konsekwencji, finansowa baza danych Y rozróżnia jednostki tylko jako kompletne zespoły, czyli jako „produkty” do sprzedania. Jednak pewnego dnia Y decyduje się na zakup podzespołów. Baza danych jednej firmy produkującej podzespoły, X, dość naturalnie rozróżnia jej pozycje na poziomie podzespołów, jak pokazano. X może opisać dwa różne modele Y całkowicie w kategoriach własnych podzespołów, z wyjątkiem przypadku c1000, który je obejmuje i który może być kupiony od innego dostawcy lub wykonany we własnym zakresie przez Y. Dodatkowo Y może nadal chcieć zachować możliwość wykonania niektórych podzespołów we własnym zakresie lub mieć możliwość zakupu podzespołów od innych dostawców. Oczywiście, chociaż Y sprzedaje rzeczy na poziomie produktu, a nie na poziomie podzespołów, Y musi teraz stworzyć jakiś sposób oddzielnej identyfikacji podzespołów w ramach swojego procesu produkcyjnego (zazwyczaj poprzez organizację rysunków montażowych w swoim biurze kreślarskim), ale niekoniecznie w jego finansowej bazie danych. Y ma spory problem: produkty nie mapują jeden do jednego na podzespoły, przynajmniej na kody stosowane przez dostawców podzespołów. Są dalsze komplikacje: X użyje wielu różnych komponentów do budowy swoich podzespołów, niektóre z nich może z kolei kupić od swoich dostawców. X musi identyfikować te komponenty jako odrębne elementy pod względem zakupów, ale jeśli funkcjonalność jest taka sama, nie musi rozróżniać ukończonych podzespołów na podstawie marki komponentów, które zawierają. Ale „funkcjonalność” jest trudna do zdefiniowania: X mógł dostarczać podzespoły do ​​firmy Z, która umieszcza je w pojemnych skrzyniach, gdzie niewielka różnica wymiarowa podzespołów spowodowana przez różne komponenty nie stanowi problemu, ale przypadki Y mogą być mniejsze. Tak więc istnieją przypadki, w których Y wymaga, aby X przyjął drobniejszą szczegółowość specyfikacji, niż X kiedykolwiek uważał za konieczny do jej wewnętrznego użytku. Zagmatwane? Taki właśnie ma być ten przykład, ponieważ przedstawia on naprawdę mylące problemy z nomenklaturą danych, które pojawiają się każdego dnia, gdy firmy decydują się na zintegrowanie swoich transakcji. Określenie, jakie dane należy przekazać, co te dane „oznaczają” i co z nimi zrobić, jest bardziej złożone niż na pierwszy rzut oka. Jak pokazuje rysunek 2.2, musimy kierować całość z punktu widzenia biznesowego – zrozumienie, czym naprawdę „jest” produkt – a następnie opisać dane i procesy, które definiują i manipulują ciągiem informacji używanym do opisania produktu i wszystkie operacje komputerowe z tym związane. Zwróć uwagę, że w omawianym przykładzie rozważaliśmy sytuację obracającą się wokół „produktu”. Istnieją inne możliwe punkty widzenia (na przykład punkt widzenia procesu dla odprawy celnej towarów), ale podstawowe zasady pozostają takie same: najpierw zdefiniuj punkt widzenia biznesowego, a następnie struktury danych i procedury, a następnie cięcie kodu. Podany przez nas przykład mógł być mylący, ale i tak było to uproszczenie. To znacznie prostsze niż w prawdziwym życiu. Aby zilustrować tę kwestię, przyjrzyjmy się teraz dalszemu przykładowi. Nadal patrzymy na rzeczy z punktu widzenia produktu. Co może być bardziej odpowiedniego przy wyborze przykładu produktu niż „książka”?

To truizm, że toniemy w nadmiarze danych. Niektóre duże organizacje przechowują terabajty informacji o własnych procesach i klientach. Było to prawdą, zanim firmy przyjęły szeroko sieciowe podejście do gromadzenia danych i zanim zaczęły handlować elektronicznie ze swoimi klientami i dostawcami, i staje się to coraz większym problemem. Dzisiejszym modnym hasłem jest zarządzanie wiedzą, konwersja tych surowych danych na znaczące informacje w kontekście modelu biznesowego, a zatem potencjalnie zdolne do wspierania planowania i podejmowania decyzji. Wiedza nie jest postrzegana jako pasywna; jest raczej uważany za przefiltrowany, skoncentrowany, możliwy do przypisania i zrozumiały wkład do rzeczywistych procesów biznesowych, bez którego nie będą one działać efektywnie. Wiele na ten temat napisano, ale jak dotąd wiele pozostaje do udowodnienia. Zamiast rozwijać więcej teorii, skoncentrujemy się na kilku kwestiach implementacyjnych związanych z obsługą eksplozji informacji.