Miesiąc: maj 2022

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.

Należy zauważyć, że krytycznym elementem systemu przepływu pracy jest struktura katalogów przedsiębiorstwa, którą można skalować w całym przedsiębiorstwie. Widzieliśmy, że istnieje potrzeba przechowywania szczegółowych informacji na temat praw dostępu i haseł ludzi; udostępnianie centrum obsługi telefonicznej, poczty elektronicznej i aplikacji do pracy grupowej wymaga spójnych planów adresowania i numeracji; gdzie indziej opisujemy, jak planowanie i inne procesy zorientowane na ludzi są kluczowymi elementami zarządzania łańcuchem dostaw. W kategoriach baz danych, poszczególne osoby działają jako unikalne klucze główne do innych informacji, które mogą być rozłożone w różnych repozytoriach danych. Rozsądnym argumentem może być zaprojektowanie wirtualnych organizacji wokół koncepcji jednej logicznej bazy danych lub katalogu, który przechowuje informacje o wszystkich — klientach, pracownikach, kontrahentach — zaangażowanych w handel. Wszystkie prawa, przywileje, umiejętności, preferencje, płatności itp. powinny być powiązane z tymi danymi i powinny być wykorzystywane jako główne źródło do wiązania zmiennych we wszystkich procesach biznesowych – zatwierdzanie finansowe, marketing ukierunkowany, płatności, pokwitowania, zamówienia towarów itp. Na stronie 138 wspomnieliśmy o protokole Lightweight Directory Applications Protocol (LDAP), który staje się de facto standardem dla aplikacji tego typu. Jedną z jego znaczących zalet jest to, że jest oparty na zasadach katalogowania X500, a X500 jest podstawą w przypadku wielu usług katalogowych w sieci LAN znacznie ułatwia to integrację sieci LAN i WAN. LDAP został przyjęty jako katalog poczty elektronicznej dla przeglądarek internetowych Netscape i Microsoft. Znaczenie tego, jeśli chodzi o wykupione rozwiązania do pracy grupowej, polega na tym, że powinny one być wystarczająco otwarte, aby móc pobierać informacje z tej bazy danych i używać ich do powiązania zmiennych nazw ze swoimi procesami, zamiast mieć własne, zamknięte struktury katalogów . Testem wyspecjalizowanego produktu może być to, czy obsługuje on katalog zewnętrzny, taki jak LDAP, lub czy nie można go otworzyć dla procesów innych niż natywne. Ważne jest również, aby można go było skalować do działania, nie tylko w sieci LAN, ale w szerokim obszarze, co może wymagać ponownego zdefiniowania, gdy partnerzy przedsiębiorstwa przychodzą i odchodzą.

Przechodząc teraz do prawie całkowicie „procesowego” spojrzenia na pracę rozproszoną, możemy rozważyć każde zadanie, które angażuje wiele osób lub jednostek organizacyjnych, które można opisać w kategoriach wielu podzadań, które działają równolegle lub szeregowo, podobnie sposób, w jaki są one opisane na standardowych diagramach aktywności, na przykład na wykresie PERT .

Podzadania muszą zostać zakończone i uznane za zakończone przez właściwy organ, zanim ich wyniki zostaną przekazane jako dane wejściowe do następnego w serii. Wszelkie komunikaty lub inne dane wyjściowe dla następnego etapu muszą być zdefiniowane w zestawie reguł. Automatyzację tych procesów osiąga się za pomocą tak zwanego oprogramowania workflow. Rozważmy przykład zamówienia zakupu. Inżynier chce zakupić dodatkowy materiał do wykorzystania w zadaniu budowlanym. Mogą wysłać żądanie zamówienia, które trafia do B, kierownika zespołu, który musi zatwierdzić, że żądanie jest konieczne, oraz do C, organu finansowego, który potwierdzi, że mieści się ono w limitach wydatków. Zamówienie może również w tym samym czasie trafić bezpośrednio do jednostki zakupowej D w celu zarezerwowania miejsca w kolejce. Jeśli wszystko pójdzie zgodnie z planem, jednostka kupująca otrzyma potwierdzenie zgody od dwóch władz i będzie mogła kontynuować zakup. Być może bardziej do rzeczy, ludzie w jednostce zakupowej nie muszą wydawać żadnej energii na zamówienie zakupu, być może nawet nie są świadomi jego istnienia, dopóki nie zostaną autoryzowane. Komunikaty pomiędzy różnymi stronami transakcji to zazwyczaj formularze elektroniczne, które zostały stworzone przez projektanta systemu za pomocą zestawu narzędzi workflow. Jak sama nazwa wskazuje, formularze te „przepływają” następnie przez system, który generuje następny zestaw formularzy tylko wtedy, gdy otrzyma całkowicie autoryzowany zestaw formularzy z poprzednich podzadań. Niejawnym elementem tego procesu jest wymaganie funkcji planisty, która monitoruje kompletność podzadań i kontroluje przepływ

Do tej pory opisaliśmy stan rzeczy, który pojawia się, gdy wszystko przebiega zgodnie z planem. Ostatnią zasadniczą cechą przepływu pracy jest potrzeba włączenia obsługi wyjątków, aby poradzić sobie z nierzadkim wystąpieniem czegoś, co nie działa

Typowe przykłady to przypadek niekompletnego formularza, zamówienia przekraczającego limit gotówki lub zapytania organu dotyczącego zasadności zamówienia. Na przykład nasz inżynier może chcieć złożyć zamówienie na więcej materiałów, ale lider zespołu może chcieć zapytać, czy jest to naprawdę konieczne. Mogą więc „odbić” formularz z powrotem z adnotacją „Proszę uzasadnić”. Wiadomość ta może pojawić się w wielu formatach: formularz w aplikacji internetowej, który musi zostać wypełniony przez odbiorcę, lub automatycznie wygenerowana wiadomość e-mail, która wymaga odpowiedzi do systemu pracy grupowej (nie do ludzkiego lidera projektu). Program obsługi wyjątków i program planujący są połączone. Wyjątek staje się samodzielnym podzadaniem, a planista, wiedząc, że podzadanie nie jest ukończone, wstrzymuje postęp do następnego podzadania, dopóki inżynier nie odpowie, a kierownik zespołu nie zatwierdzi tej odpowiedzi jako akceptowalnej. Tradycyjnie oprogramowanie zorientowane na procesy było pisane we własnym zakresie i generalnie było opracowywane w kawałkach, z regułami i harmonogramami w sposób dorozumiany, a nie wyraźnie zdefiniowany i obejmujący tylko część kompleksowych zadań firmy. Nadal często dochodziło do ręcznego przekazywania między tymi procesami, często z ponownym wprowadzaniem klucza i innymi czynnościami podatnymi na awarie. W ostatnich latach firmy takie jak Staffware opracowały pakiety i narzędzia, które pozwalają na tworzenie systemów przepływu pracy przy znacznie mniejszej potrzebie angażowania się w szczegółowe programowanie, a tym samym uwalniają wysiłek, aby skoncentrować się na modelowaniu procesu. Z punktu widzenia architektury produkty związane z przepływem pracy w naturalny sposób opierają się na architekturach klient-serwer, przy czym formularze są dostarczane na komputery klienckie, a harmonogramy i zasady oparte na regułach działają w koncentratorze serwera. Nowoczesne rozszerzenia do tego obejmują teraz interfejsy internetowe i metodologie obiektów/komponentów typów. Przejście do przetwarzania rozproszonego, integracja poprzez DCOM, CORBA i Enterprise JAVA, oznacza na przykład, że kod przepływu pracy może wchodzić w interakcje z już złożonymi procesami i kolejkami zadań, opracowanymi wcześniej wewnętrznie lub przy użyciu innych zakupionych produktów procesów i baz danych. Rzeczywiście, oprogramowanie sprzedawane pod nazwą „przepływu pracy” jest coraz częściej pozycjonowane jako oprogramowanie integracyjne, które ma łączyć częściowe, zastrzeżone rozwiązania z węższymi zadaniami. Rozpoczynając wprowadzanie oprogramowania do pracy grupowej, należy również wziąć pod uwagę istniejące wewnętrzne planowanie zasobów przedsiębiorstwa (ERP). ERP jest raczej zintegrowanym rozwiązaniem bazodanowym niż silnikiem opartym na procesach do prowadzenia przedsiębiorstwa, ale różnice zaczynają zanikać.