Zrób Sobie Firmę

Początkowo każda ze stron internetowych składała się z pojedynczego dokumentu pobranego z lokalizacji na serwerze, a następnie być może wklejonego do niego z pewną liczbą grafik. Późniejsze generacje przeglądarek opracowały to, aby umożliwić ekranowi jednoczesne wyświetlanie wielu ramek: stron internetowych, z których każda jest w pełni niezależna, ale jej względny rozmiar i położenie są dyktowane przez pojedynczą stronę zestawu ramek, która steruje wyświetlaniem  . Jednym z bardzo wygodnych zastosowań jest wyświetlanie paska narzędzi, być może mocno oznakowanego logo firmy, przy jednoczesnym umożliwieniu użytkownikom przeglądania kolejnych pozycji w katalogu przedstawionym w innej ramce. Rysunek przedstawia dwa widoki ekranu renderowane w ten sposób.

Po lewej stronie widzimy ekran powitalny, który składa się z dwóch ramek, ramki menu i ramki powitalnej. Wybranie linku do naszych produktów powoduje wyświetlenie dwóch ramek po prawej stronie rysunku. Skrajna prawa strona prowadzi do dalszego wyboru, ale druga ramka nadal pokazuje to samo menu, co poprzednio, pomagając w ten sposób w nawigacji. Istnieje jednak kwestia odpowiedniego wykorzystania ramek, a debata na ten temat jest prawdopodobnie najczęstszym argumentem dotyczącym projektowania stron internetowych, z jakim spotkają się niespecjaliści. Są ludzie, którzy uważają, że nigdy nie należy używać ramek; są inni, którzy wierzą, że mogą być przydatne w pewnych okolicznościach. Z pewnością prawdą jest, że łatwo można przesadzić z używaniem ramek, co może prowadzić do znacznego zamieszania użytkowników. Użytkownicy nie zawsze są pewni, jak obie części obrazu odnoszą się do siebie, zwłaszcza jeśli tła są identyczne i jedną część obrazu (tj. jedną ramkę) można przewijać niezależnie od drugiej. Możliwe jest również uzyskanie niezwykle skomplikowanego ekranu, gdy linki do witryn stron trzecich również wykorzystują ramki. Drugi problem pojawia się, gdy dostawca chce wyświetlić własną witrynę innej firmy. Może tak być w przypadku, gdy firma tworzy „centrum handlowe”, które składa się z wielu witryn internetowych sprzedawców, otoczonych zestawem ramek własnego projektu, prawdopodobnie pełniących rolę nawigatorów w centrum handlowym. Jeśli jakiś sprzedawca ma również witrynę z ramkami, wyniknie niechlujny i mylący zestaw ramek w ramkach. Zwykle nie można też obejść problemu, po prostu łącząc się ze stronami informacyjnymi sprzedawcy. Prawie zawsze zestaw ramek sprzedawcy będzie zawierał pasek narzędzi, który będzie musiał zostać zastąpiony czymś dostarczonym przez właściciela centrum handlowego, co spowoduje wzrost kosztów i znaczne koszty utrzymania. W każdym razie nie zawsze dobrym pomysłem jest umożliwienie użytkownikom uzyskiwania bezpośrednich linków do stron osób trzecich.

Dla wielu tradycyjnych organizacji otwarcie ich sklepu internetowego było działaniem eksperymentalnym, być może nawet nie zaakceptowanym przez główne organizacje zajmujące się sprzedażą i marketingiem. Często też tak to wygląda! Wiele witryn zostało zaprojektowanych przez kogoś z działu IT, często w wolnym czasie, bez większych umiejętności projektowania graficznego lub zastanowienia się nad tym, jak zintegrować to, co często jest wyświetlaniem tylko próbki produktów, z głównym katalogiem. „Praca w Internecie” jest zbyt ważna, aby pozostawić ją w niepełnym wymiarze godzin, niespecjalistom. To praca dla zespołu marketingowego. eShop powinien być reprezentantem marki firmy, „niematerialne korzyści najlepiej interpretowane jako wzbudzanie zaufania klientów” . Źle zaprojektowana, zawodna, niejednolita strona internetowa staje się zatem symboliczna  dla firmy o podobnym etosie i wydajności. Proces tworzenia witryny eCommerce, która zamiast tego przedstawia pozytywny wizerunek organizacji, jest dość złożony. Wymaga odpowiedniej mieszanki umiejętności i ludzi. Powodem złożoności jest to, że trzeba osiągnięcia spójnego zrozumienia i równowagi między potrzebami i oczekiwaniami użytkowników a ograniczeniami technologii. Oczywiście nie jest to przypadek wyjątkowy. Prawie każdy rozwój oprogramowania spełnia ten wymóg: witryna eCommerce jest „tylko” jeszcze jednym przykładem interaktywnego projektu multimedialnego. Wiadomo, że są one trudne! Kolega kiedyś opisał takie działania jako „próba nawiązania współpracy Baletu Bolszoj (grafików) i Armii Czerwonej (programistów) pod kontrolą KGB (dyrektor projektu)”. Rzeczywiście, umiejętności prawdopodobnie leżą w kierownikach projektów i większość z nich pochodzi z praktyki. Możliwe jest korzystanie ze studiów projektowych, ale zawsze będą one wymagały „krótkiego” z góry lub opracowanego z organizacją w ramach kosztów umowy. Rysunek, przedstawia standardową metodę tworzenia profesjonalnych projektów.

Marketerzy zauważą, że jest to metoda podobna do metody stosowanej przy projektowaniu większości kampanii marketingowych. Nieuchronnie będzie szeroko wykorzystywał storyboardy. Scenorysy stanowią wspólne medium dla programistów technicznych, stylistów i osób zlecających marketing w celu konceptualizacji i udoskonalenia wyglądu i funkcjonalności projektu. Może to być przeprowadzone w środowisku „warsztatowym”, przy użyciu białych tablic i flipchartów, ale ostatecznie zaowocuje demonstratorem koncepcji, zakodowanym w jakimś języku prototypowania (np. Visual Basic) lub być może bezpośrednio w HTML, po którym nastąpi być poważnym przeglądem. Równolegle z tym działaniem przebiega tworzenie żywego dokumentu, przewodnika po stylu aplikacji, który rejestruje stylizację i branding, a także funkcjonalne aspekty nawigacji itp. Przewodnik jest kończony po zakończeniu fazy projektowania i działa jako podręcznik referencyjny dla programistów i klienta. Opisany proces to dobry sposób, aby wszystkie strony myślały podobnie, przy minimum nieporozumień. Punkty, na które należy jednak zwrócić uwagę, to tworzenie powszechnego nieporozumienia dotyczącego wydajności i sytuacji, a także zbyt optymistyczne spojrzenie na entuzjazm klienta końcowego. Wydajność może być zwodnicza: pamiętaj, że demonstrator prawdopodobnie działa dla jednego użytkownika siedzącego lokalnie. Zastanów się, jak może się zachowywać, gdy jest spowolniony przez wielokrotne dostępy i ograniczenia połączenia modemowego. Studio projektowe nieuchronnie też będzie próbowało zademonstrować prototyp na dużym, wysokiej jakości monitorze, korzystając z przeglądarki zgodnej ze środowiskiem projektowym. Upewnij się, że próby są przeprowadzane przy użyciu pełnej gamy platform dostępowych i środowisk transmisyjnych. Wszystko to przetestuje użyteczność systemu; o wiele trudniej jest wypróbować jego użyteczność (przydatność), chyba że zamierzasz wesprzeć demonstrację realistycznymi pilotami obejmującymi dostarczanie realistycznych usług. To dobry pomysł z kilku powodów. Nie tylko będziesz mógł zacząć zadawać swoim klientom pytania dotyczące ceny, jaką naprawdę zapłaciliby za taką usługę, ale także zaczniesz koncentrować się na rzeczywistych kosztach jej świadczenia. Nacisk może wtedy zacząć przenosić się z blichtru frontowego projektu multimedialnego na twarde fakty dotyczące łańcucha dostaw. Zauważ, że jedną z naprawdę wielkich zalet świadczenia usług on-line jest możliwość poproszenia klientów próbnych o informację zwrotną on-line, być może za pomocą prostego formularza. Oczywiście ważne jest, aby nie przesadzić, ale oznacza to, że można przeprowadzić ocenę natychmiastowej reakcji klienta w znacznie bardziej skoncentrowany sposób niż w przypadku tradycyjnych badań rynkowych. Nawet jeśli postanowiono nie pytać o odpowiedź klienta, nadal możliwe jest zbieranie statystyk, które strony cieszyły się największą popularnością. Aspekty stylistyczne projektowania stron internetowych są tak naprawdę problemem dla projektantów artystycznych, a nie kwestią techniczną i wiele podręczników i kursów na ten temat zaczyna się pojawiać. Jednak stylizacja musi być przeprowadzona w ramach ograniczeń narzuconych przez technologię. Poniżej przyjrzymy się niektórym z tych problemów technicznych i ich wpływowi.

Choć eCommerce otwiera przed klientami nowy kanał, nie jest szczególnie trudno dopasować go do tradycyjnych modeli marketingu. Rzeczywiście, marketing jest nauką, kryjącą się za nią szanowaną teorię i praktykę, i jako technolodzy powinniśmy próbować ją zrozumieć, a nie wymyślać na nowo. Niemniej jednak, tradycyjni marketerzy mogą być przestraszeni lub oszukani przez nową technologię, a jednym z ważnych zadań dla technologów powinna być pomoc w dostrzeżeniu nowych.

Nic dziwnego, że pojawiło się wiele obaw dotyczących bezpieczeństwa rozwiązań kodu mobilnego, szczególnie w przypadku negocjacji dotyczących zamówień i pieniędzy. Kwestie bezpieczeństwa omawiamy ogólnie w części 3, ale właściwe jest omówienie tego konkretnego problemu tutaj. Jaki jest problem? W rzeczywistości istnieją dwa główne problemy: szkody, jakie kod mobilny może wyrządzić systemowi, do którego uzyskuje dostęp, oraz wzajemna możliwość złośliwego uszkodzenia agenta przez system. Aktualne badania wskazywałyby, że ten ostatni problem jest potencjalnie bardziej niebezpieczny. Używanie technik piaskownicy  w celu ograniczenia agenta do określonej części pamięci hosta odbierającego jest silną obroną; jak opisano w cytowanej referencji, możliwe jest również wyposażenie agentów z własnymi cyfrowymi certyfikatami i podpisami. Nadal występują problemy z atakami typu „odmowa usługi” poprzez złośliwe spawnowanie agentów, które zużywają moc obliczeniową hosta, ale jest to już zagrożenie w przypadku ataków bez agentów. Trudniej jest zapobiec atakowi na agenta mobilnego, na przykład zmieniając oferowane lub akceptowalne ceny strategii negocjacyjnej. Agent musi „otworzyć się” bardziej niż gospodarz; dlatego gospodarze mogą w większym stopniu zajrzeć do środka. Możliwa jest jednak pewna ochrona: agenty mogą być duplikowane i takie, które można przechowywać w chronionym środowisku w porównaniu z zagrożonym agentem. Te komentarze tylko zarysowują powierzchnię niezawodności i bezpieczeństwa agenta mobilnego. Temat jest wciąż na wczesnym etapie i trzeba przeprowadzić więcej badań. To, w połączeniu z nieznaną wydajnością agentów mobilnych jako negocjatorów twardych negocjacji, prawdopodobnie oznacza, że ​​w pełni zautomatyzowane negocjacje handlowe (z wyjątkiem stron ufających w bezpiecznych sieciach) będą rosły powoli w ciągu najbliższych kilku lat. Jeszcze przez jakiś czas zautomatyzowani agenci będą wykorzystywani jako asystenci agentów zajmujących się zakupami ludzi, być może jako „wyszukiwacze” stron, które chcą negocjować.

Do tej pory koncentrowaliśmy się na samowystarczalnej i adaptacyjnej naturze agentów oprogramowania i mogliśmy być winni sugerowania, że ​​„poruszają się” po sieci, polując na okazyjne witryny. W rzeczywistości większość z nich nic takiego nie robi. Wiele z nich znajduje się po prostu na komputerze klienckim i po prostu ściąga strony internetowe, które analizują lokalnie. Jednak niektórzy agenci posiadają również właściwość mobilności. Oznacza to, że fragmenty kodu wykonywalnego, reprezentujące instancje agentów, mogą być uruchamiane, powiedzmy, z klienta na serwer lub odwrotnie, aby uruchomić jakiś proces na tym ostatnim. Możliwe jest również uruchomienie kilku agentów w sieci komputerowej, z których każdy zajmuje się rozwiązywaniem tego samego zadania lub jego wariantów. Oczywistym zastosowaniem może być próba znalezienia ceny za krótkotrwały towar – na przykład umowę dotyczącą usług finansowych lub miejsce w linii lotniczej. Przykład tego ostatniego podano w [136]. Agent następnie uruchamia się na hoście docelowym, być może negocjując z innymi agentami i albo wysyłając prostą wiadomość „o zakończeniu” do swojego nadawcy, albo uruchamiając się albo do oryginalnego hosta albo do innego komputera, przy czym projekcja samego siebie zawiera informacje do dalszego przetwarzania. Problemy tutaj wyraźnie dotyczą przeciążenia sieci i reakcji na jej awarię lub opóźnienia, problemów z wydajnością uruchamiania wielu agentów na „obcych” maszynach i bezpieczeństwa. Aby rozwiązać te problemy, opracowano szereg wdrożeń [137]. Wszystkie nakładają ograniczenia na swobodę działania agenta w systemie hosta, być może przypisując go do określonych wirtualnych miejsc w pamięci, ograniczając jego prawa dostępu do określonych miejsc na serwerze plików i przerywając go, jeśli wystąpią anomalie procesora. Dobre systemy w dużym stopniu wykorzystują również zabezpieczenia, oparte na przekazywaniu poświadczeń kryptograficznych („certyfikaty”), które można wykorzystać do wywołania uprawnień dla agenta (dostęp do plików, maksymalny czas procesora itp.). Aspekty wydajności i niezawodności zostały potraktowane na wiele różnych sposobów: niektóre systemy wolą traktować każdego agenta jako pojedynczy wątek w pojedynczym, wielowątkowym procesie, co przyspiesza komunikację między agentami kosztem złożoności; inni uruchamiają każdego agenta jako oddzielny proces w środowisku wielozadaniowym. Systemy mogą być całkowicie rozproszone lub obejmować centralny serwer, który nadzoruje każdą interakcję. Większość systemów jest interpretowana, a nie kompilowana, a JAVA jest szeroko stosowana. Prowadzi to do dość niskiej wydajności w porównaniu ze skompilowanymi rozwiązaniami.

Choć jest to proste, czynność pojedynczego zakupu ilustruje podstawowe elementy rozwiązania opartego na agentach. Celem wielu dzisiejszych badań jest jednak ukierunkowanie na rozwiązanie działań wewnątrz- lub międzybiznesowych, które są znacznie bardziej złożone. W szczególności agent ma znacznie większą potrzebę dostosowania swojego zachowania, często w ramach jednego zadania, aw wielu przypadkach zaangażowanych jest kilku agentów. Większość z tych prac jest nadal wysoce eksperymentalna i została przetestowana tylko w łagodnych środowiskach: nikt nie wydaje się być gotowy na postawienie swojego agenta przeciwko innym w prawdziwie wojowniczych negocjacjach handlowych. Konstruując ramy agenta negocjacyjnego, ponownie należy jasno określić cele i strategie. Zwykle mają znacznie wyższy „wymiar”, ponieważ optymalne rozwiązanie należy znaleźć, manipulując wartościami wielu zmiennych w wielu agentach. Dla każdego agenta staramy się zdefiniować funkcję kosztową. Może to być kompromis między terminem ukończenia, ceną, stanem magazynowym itp. Faza negocjacji polega na tym, że każdy z tych agentów stara się osiągnąć wynik, który obniży koszty do satysfakcjonującego poziomu pod względem założonych celów. Zauważ, że rozwiązanie jest poszukiwane na satysfakcjonującym, a nie minimalizującym funkcję kosztu. Matematyka i wynikające z niej obliczenia mogą być wymagające; często problem musi być posegmentowany, sparametryzowany i rozwiązywany dla lokalnych optimów, a nie globalnych [134]. (Niekoniecznie musi to być wadą: algorytmy stojące za zoptymalizowanymi, niesparametryzowanymi rozwiązaniami mogą być trudniejsze do rozszyfrowania dla agentów konkurencji. Jak dotąd niewiele pracy włożono w ten kryminalistyczny aspekt negocjacji agentów.) Cały obszar projektowanie agentów jest obecnie bardzo aktywnym obszarem badań (w przeciwieństwie do wdrożeń), obejmującym zagadnienia sprawnego wdrażania w heterogenicznych środowiskach rozproszonych oraz projektowania strategii negocjacyjnych.

Opisany poprzednio agent handlowy wykonał proste zadanie, które zresztą zostało naprawione. Jego interakcja ze światem została pokazana na rysunku

Agent znalazł to, czego chciał i powiedział użytkownikowi. Ale załóżmy, że użytkownikowi nie spodobało się to, co zobaczył? A może użytkownik kupił wtedy towar i miał złe doświadczenia z dostawą od konkretnego sprzedawcy? Oczywiście powinien istnieć sposób na modyfikację zachowania agenta w celu poprawy przyszłych wyników w odpowiedzi na informacje zwrotne ze świata zewnętrznego (w tym przypadku klienta

Cel pozostał ten sam, ale strategia obejmuje teraz zdolność adaptacyjną, która reaguje na otoczenie zewnętrzne. Adaptacyjni agenci tego typu są wykorzystywane do wielu zadań, głównie do selektywnego wyszukiwania informacji, w ramach opisów profilowania osobistego, preferowania itp. Mają one na celu stopniowe poznawanie preferencji osób i dostarczanie tylko tych informacji, które spełniają określone wymagania. profil użytkownika na podstawie poprzedniego wyboru. Mechanizm uczenia się może być zainicjowany przez indywidualnego użytkownika, który opiniuje wcześniejsze informacje dostarczone przez agenta lub w wyniku zbiorowych decyzji zebranych przez agenta centralnego i rozesłanych do poszczególnych agentów użytkownika jako informacja zwrotna ze świata zewnętrznego. Wyjaśniając to ostatnie bardziej szczegółowo: wyobraź sobie, że zbierasz informacje o wyborach filmowych wielu użytkowników. Analiza statystyczna prawie na pewno wykaże, że grupa użytkowników, którzy lubią jeden film bardziej niż przeciętna populacja, będzie również podzielała wspólną opinię o innym filmie. Tak więc, jeśli mój agent zebrał tabelę moich upodobań i niechęci, może zaoferować ją agentowi maklerskiemu, który może przechowywać tabele preferencji dla dużej populacji widzów. Porównując moje sympatie i antypatie z preferencjami innych widzów, można zidentyfikować filmy, które widzowie o podobnych poglądach widzieli i polubili, ale których ja nie widziałem. Agent brokerski może następnie wysłać te informacje do mojego spersonalizowanego agenta, mówiąc: „Myślę, że ci się to spodoba”. Jeśli zdecyduję się go obejrzeć, zostaniesz poproszony o jego przejrzenie, a to doprowadzi do modyfikacji mojej tabeli preferencji. Oznacza to, że element adaptacyjny wszedł w strategię doboru mojego agenta. (Ale nie do mojego celu, którym pozostaje „Znajdź przyjemny film”).

Chociaż jest to tak naprawdę kwestia handlu detalicznego, a nie business-to-business, jest to pouczający przykład na początek. Specyfikacja jest prosta: zaprojektuj agenta handlowego, który może znaleźć „najlepszą” ofertę na konkretny produkt, wyszukując go w sieci. W ten sposób problem jest zwykle określany w powierzchownych stwierdzeniach o cudownych mocach zautomatyzowanych agentów i często twierdzi się, że „wkrótce” tę zdolność osiągną. To oczywiście straszna specyfikacja, której żaden człowiek, nie mówiąc już o maszynie, nigdy nie powinien zaakceptować. Nie można go też rzetelnie ocenić. Przede wszystkim cel nie jest wystarczająco dobrze zdefiniowany. Co rozumiemy przez „najlepszy”? Czy mamy na myśli najniższą cenę? Najszybsza dostawa? Jak szybko oczekujemy odpowiedzi? (Czy naprawdę mamy przeszukiwać całą sieć?) i tak dalej. Widzimy, że nawet ten bardzo prosty przykład wymaga gruntownej analizy polityki biznesowej kupowania najlepszej oferty (np. „zdobądź najtaniej!”). Musimy również określić zaangażowany proces biznesowy („Przejdź do wybranej listy witryn internetowych w celu uzyskania informacji o cenach; odeślij wynik przed przerwą obiadową” itp.). Już teraz musieliśmy włożyć duży wkład człowieka w to, co ma być procesem zautomatyzowanym. Załóżmy jednak, że udało nam się określić, czego chcemy i na jakich warunkach. Następnie musimy to określić w zestawach standardowych terminów. Proces zakupowy definiujemy w kategoriach stosunkowo niekontrowersyjnych elementów: wyszukania specyfikacji, sprawdzenia warunków, sprawdzenia historii kredytowej, podania szczegółów płatności i dostawy itp. Możliwe, że te elementy z kolei mogą być zbudowane z zestawów wspólne obiekty biznesowe (CBO). Jest to jeden z celów Object Management Group (OMG – patrz strona 149), która stara się osiągnąć standaryzację w tym obszarze. Nie ma sensu próbować minimalizować „ceny”, jeśli termin nie został zdefiniowany, czy to jako przedmiot, czy jako część innego. Musimy wstrzymać się z oceną, kiedy rzeczywiście, czy OMG odniesie pełny sukces w zidentyfikowaniu wszystkich niezbędnych CBO. Jeśli jednak agenci stworzeni przez różne strony mają w ogóle móc negocjować, będzie musiała istnieć przynajmniej wspólna definicja istotnych „rzeczy” (najprawdopodobniej „obiektów”), które są zaangażowane w transakcję. Od każdej próby narzucenia modelu obiektowego na poziomie biznesowym wymagane jest również to, aby rozsądnie mapował on komponenty oprogramowania pośredniego w starszych systemach. Jest prawdopodobne, że Extensible Mark-up Language (XML) będzie odgrywał ważną rolę w definiowaniu elementów, które składają się na proces handlu online. Jak omówiono na stronie 179, XML zapewnia prosty i skalowalny sposób definiowania terminów i publikowania tej definicji on-line. W najprostszej formie moglibyśmy wyobrazić sobie grupę dostawców, prywatnie lub za pośrednictwem stowarzyszenia handlowego, ustalających uzgodnioną definicję terminów takich jak „producent”, „model”, „cena”, „ilość”, „termin dostawy”. ‘, i tak dalej. Zgadzają się opublikować ten zestaw definicji on-line, jak na przykład definicja typu dokumentu XML (DTD), która będzie zawierać listę tych nazw i być może jednostek, w których są wyrażone. Następnie możemy sobie wyobrazić, że uwzględnią te terminy jako metatagi , gdzieś na swoich stronach katalogu on-line. Dostawca A może mieć:

To (w rzeczywistości raczej uproszczone w stosunku do rzeczywistości) mówi nam, że model CarverKing jest dostępny w cenie 500 funtów w ciągu 30 dni. Z drugiej strony sprzedawca B może zaoferować:

To znaczy droższa, ale szybsza dostawa. Teraz zaczynamy dostrzegać, jak można zaprojektować bardzo prostego agenta zakupów, aby sprawdzić te witryny w celu uzyskania „najlepszej” oferty. Musimy zaprogramować agenta zgodnie z formatem DTD, aby mógł „zrozumieć”, co oznacza „model”, itp. Następnie potrzebujemy interfejsu, który pozwoli użytkownikowi wpisywać informacje zgodnie z tymi terminami. Na przykład jedno pole formularza wymagałoby informacji o „modelu”. Musimy powiedzieć agentowi, gdzie ma szukać stron, na których znajdzie metatagi, które może odczytać. Aby to zrobić, musimy zdefiniować strategię. Ponownie, parametry dla tego są ustawione przez człowieka. Jedną z możliwości byłoby po prostu powiedzieć mu, aby „idź do Altavista i wyszukał to, co użytkownik umieścił w modelu. na formularzu internetowym agenta (w tym przypadku „CarverKing”). Altavista zwróci adresy URL wielu trafień. Agent jest teraz zaprogramowany tak, aby odwiedzał kolejno każde z tych trafień i szukał dowodów użycia metatagów ,producent, ,model itp. i ewentualnie odniesienia do DTD. Ten dowód powie agentowi, że rzeczywiście patrzy na stronę, na której towary są opisane w zrozumiałym dla niego języku i formacie. Dzięki temu może niezawodnie wydobywać informacje ze stron. Teraz musi wydać rekomendację zakupową. Jego prostym celem jest uzyskanie „najlepszej” oferty. Ale jak to najlepiej definiuje? Właściwie ponownie wymagana jest interwencja człowieka. Musi istnieć definicja „najlepszego” dostarczona agentowi przez osobę, która chce kupić towar. Agent jest „tylko człowiekiem”, przynajmniej pod tym względem! „Najlepszy” można by określić jako „najtańszy”, w którym tylko „cena”. informacje zostaną wykorzystane. Być może preferowany jest bardziej złożony algorytm: użytkownik może określić równowagę między ceną a dostawą. (Można obliczyć ważoną sumę ceny i daty dostawy, być może również z ogólnymi limitami na którekolwiek z nich.) Algorytm ten zostałby zaprogramowany jako strategia podrzędna. To, co chcemy w tym wszystkim wyjaśnić, to niemagiczna natura tego procesu. Po pierwsze, nie ma możliwości, aby agenci mogli odgadnąć cele zakupowe użytkownika, mimo że, jak zobaczymy, mogą uczyć się z doświadczenia. Po drugie, wybór agenta będzie tylko tak dobry, jak pozwala na to strategia, a większość strategii jest stosunkowo naiwna. Nikt nie może zagwarantować, że znajdzie „najlepszy zakup”, nawet przy jasnej definicji celu. Oczywiście agenci mogą mieć bardziej inteligentne strategie niż w przykładzie opisanym powyżej. Miało to tę zaletę, że przy użyciu specyfikacji XML, było mało prawdopodobne, aby pomyliły się w faktach. Ale równie dobrze mogło przegapić lepsze oferty, które nie zostały zaprogramowane w XML. Wiele badań nad agentami jest zaangażowanych w budowanie agentów, którzy potrafią podejmować dobre próby czytania wolnego tekstu, zamiast tego, który został celowo metatagowany zgodnie z ustalonym planem. Daje to więcej odpowiedzi i być może lepsze okazje, ale kosztem niezawodności.

Często mówi się, że systemy transakcyjne on-line są uruchamiane przy użyciu sztucznych inteligentnych agentów, którzy będą negocjować między dostawcą a konsumentem. CORBA i inne podobnie rozproszone środowiska przetwarzania wyraźnie ujawniły modele obliczeniowe, w których scentralizowana kontrola nie jest już dominującym paradygmatem: procesy są uruchamiane tam, gdzie system decyduje, że mogą działać najlepiej, a decyzja ta jest podejmowana poprzez wymianę mocy obliczeniowej, a nie jej centralne przypisanie (patrz Część 2, Architektura systemów e-biznesowych). W zasadzie nie ma powodu, dla którego uprawnienia decyzyjne miałyby ograniczać się do wyboru platformy obliczeniowej lub algorytmu: moglibyśmy rozszerzyć zasadę o umożliwienie autonomicznym procesom podejmowania decyzji zakupowych dotyczących dóbr rzeczywistych. Oznacza to, że przenosimy koncepcje niezależnej, ale kooperacyjnej interakcji między komponentami oprogramowania pośredniego w DCOM, CORBA itp. do warstwy aplikacji, gdzie procesy współdzielące wspólne opisy aplikacji mogą działać na różnych platformach, dążąc do uzgodnionego rozwiązania tej aplikacji. Procesy zazwyczaj komunikują się i mogą obejmować transmisję samodzielnych modułów kodu z jednej platformy na drugą. Procesy te są czasami nazywane autonomicznymi lub inteligentnymi agentami oraz, gdzie mogą „wędrować” po sieci firmowej, agentów rozproszonych lub mobilnych. W koncepcji tych agentów jest coś raczej uwodzicielskiego: czasami wydają się posiadać nadludzkie (lub z pewnością superkomputerowe) zdolności negocjacyjne. Po prostu „wrzucamy” ich do sieci, uzbrojonych w prawo do negocjowania najniższej ceny produktu lub najlepszych warunków umowy na dostawę i z tym wracają. Rzeczywistość jest nieco inna, ale agenci handlowi są czymś więcej niż tylko pustym pojęciem i mogą z czasem stać się bardzo ważnymi elementami strategii e-biznesu. Przede wszystkim, kim jest agent handlowy? Rzeczywiście, kim jest agent? Próby były podejmowane z definicji, na przykład [132], ale najbezpieczniejszą odpowiedzią jest to, że nie ma prostej odpowiedzi. Termin ten był używany na tak wiele różnych, niespójnych sposobów, że definicja jednej osoby z pewnością obrazi kogoś innego. W obawie przed dodaniem do debaty, ale w interesie dalszego rozwoju, staramy się przynajmniej dać ogólne wrażenie na temat tego, czym jest i robi agent handlowy/negocjacyjny:

* Jest to fragment kodu, który wchodzi w interakcję z innymi fragmentami kodu, aby pomyślnie zakończyć zestaw transakcji, lub przerywa działanie bez awarii systemu, jeśli nie można tego zrobić.

* Zadowalające zakończenie transakcji osiąga się, gdy osiągnięty zostanie zestaw celów w ramach agenta oraz w innych procesach, z którymi współdziała.

Kodeks zawiera strategię, dzięki której działa, aby osiągnąć swoje cele.

* Próbując osiągnąć cel lub przynajmniej podcel, agent może podejmować pewne decyzje, być może dzieląc je z „obcymi” procesami, bez bycia kontrolowanym przez jakąkolwiek zewnętrzną, scentralizowaną funkcję kontrolną.

* Agent może modyfikować swoją strategię i być może swoje cele w świetle doświadczenia.

Biorąc pod uwagę te bardzo ludzkie cechy, łatwo jest zobaczyć, które agenty oprogramowania zostały poddane antropomorfizacji. Musimy bardzo uważać, aby nie pomylić listy życzeń z rzeczywistością. Istnieje szereg aspektów architektonicznych, które przede wszystkim odróżniają rozwiązania oparte na agentach od innych mechanizmów rozwiązania:

* Konstrukcja modułu agenta jest sformułowana parafialnie – nie ma szczegółowych założeń dotyczących globalnej architektury (dostawca platformy, optymalizacja zadań w innych lokalizacjach biznesowych itp.)

* Interakcja między jednym agentem a komplementarnym procesem lub agentem, z którym wchodzi w interakcje, opiera się na negocjacjach, a nie na operacji master-slave.

* Negocjacja opiera się na regułach i formatach interfejsu, które są znane wszystkim procesom współdziałającym.

* Wewnętrzne szczegóły dotyczące przebiegu tych negocjacji niekoniecznie są ujawniane.

* W wielu przypadkach instancje agentów mogą być tworzone bez ograniczeń, każdy utworzony w ten sposób agent jest odizolowany od innych, a jego jedyna interakcja z innymi odbywa się za pomocą wcześniej uzgodnionego protokołu przesyłania wiadomości.

* Ponieważ sposób, w jaki każda konkretna instancja rozwiązywania zadania zwykle zależy od złożonej interakcji kilku instancji agentów, z których każda działa w kierunku celów, które są oparte na ich bieżącym środowisku, zwykle nie jest możliwe (lub przynajmniej bardzo trudne) określenie kompaktowy globalny algorytm, który próbują rozwiązać. Zamiast tego rezultatem jest przykład zachowania emergentnego, które wynika z ich interakcji. Czasami do opisu tego zjawiska używa się terminów system samoorganizujący się lub koneksjonizm.

* Chociaż zdolność do adaptacji zachowania w świetle przeszłych doświadczeń nie ogranicza się wyłącznie do architektur agentów (a niektórzy agenci są nieadaptacyjni), metody osiągania tego poprzez modyfikację indywidualnych celów agentów są raczej specyficzne dla nich.

Z powyższego opisu może wynikać, że oparte na agentach systemy rzeczywiście wykazują duże podobieństwo do projektowania komponentów opartego na obiektach dla rozproszonych, heterogenicznych transakcji. Współdziałają za pośrednictwem określonych interfejsów, nie są zbyt dociekliwi, jeśli chodzi o wewnętrzne mechanizmy drugiej strony, pozwalają na wielokrotne tworzenie i izolowanie tych instancji i tak dalej. Rzeczywiście, do ich projektowania często używa się metod i języków obiektowych. Na bardziej szczegółowym poziomie czasami okazuje się, że klasyfikacja typów i zastosowań agentów jest sama w sobie dziedziną badań. Odnośnik [133] dostarcza jednej użytecznej taksonomii. Zgodnie z tym, i większością innych schematów, agenci e-biznesu są członkami klasy agentów spółdzielczych i mogą być dogodnie podzieleni według funkcji na zleceniodawcę, dostawcę lub agenta maklerskiego, w zależności od tego, czy ich główną funkcją jest wyszukiwanie/konsumpcja informacji lub usług reklamować i świadczyć te usługi lub „dopasowywać” lub „pośredniczyć” między pozostałymi dwiema klasami. Interesujące jest to, że ta taksonomia sugeruje, że zawsze będzie istniał związek asymetryczny, prawdopodobnie odzwierciedlający prawa umów. Być może dlatego pouczające jest myślenie o agentach jako procesach, które negocjują zasoby, bezpośrednio lub za pośrednictwem innych agentów. Jeśli tak jest, to możemy poszukać procesów biznesowych, które mają ten „umowny” charakter i uznać je za oczywistych kandydatów do systemów agentowych. Wśród nich są oczywiste kandydatury, w tym pojedynczy zakup przez klienta, negocjacje kontraktów międzybranżowych o dostawę i odwołanie, a także, w dość innym obszarze, harmonogramowanie prac w środowisku wieloproduktowym i wieloliniowym.

Twierdzi się, że większość firm przeznacza ponad 30% swoich dochodów na zakup towarów i usług .Jeśli jest to choć trochę zbliżone do prawdziwej liczby, to jasne jest, że musi istnieć potencjał do poprawy kosztów takich transakcji, jak również ich jakości. Ale najpierw powinniśmy stworzyć ducha: istnieje naiwne przekonanie, że technologia informacyjna on-line nieuchronnie prowadzi do otwartego, oportunistycznego rynku, na którym dostawcy oferują towary i usługi „rozwiązły” na szerszym rynku, a nabywcy mogą, odpowiednio, kupują, według własnego uznania, poza ich tradycyjnymi dostawcami. Dowody empiryczne wykazały, że wydaje się, że jest odwrotnie. Analiza przeprowadzona przez nieżyjącego już profesora Geoffa Locketta w Leeds Business School [komunikacja prywatna] pokazuje, że firmy handlują z mniejszą liczbą dostawców, a nie z większą. Przyczyny tego nie są jasne, ale podejrzewa się co najmniej dwa czynniki: po pierwsze, w obszarze zakupu krytycznych komponentów firmy wolą płacić niewielką premię za bezpieczeństwo prowadzenia interesów z kimś, kogo znają i którym ufają. Według Locketta, ponad dwie trzecie zakupów dokonywanych jest między organizacjami, które uważają, że współpracowały ze sobą dla obopólnych korzyści i będą to robić nadal. (Omówimy kwestie zaufania bardziej szczegółowo w Części 3, Zaufanie.) Po drugie, teoretyczna swoboda oferowana przez IT jest często niwelowana przez praktyczne wdrożenie z wykorzystaniem zastrzeżonych standardów, co oznacza, że ​​bardzo trudno jest handlować poza relacją bez rozległego ponownego kodowania i zakup kapitału. Niemniej jednak na niektórych rynkach, szczególnie tam, gdzie oferowane towary są towarami utowarowionymi, a poziomy zaufania są jednolite, istnieje elastyczny handel on-line. Podstawowe towary, takie jak ropa, od pewnego czasu kupowane są w ten sposób na rynkach spotowych, często przez telefon lub teleks. Ostatnio w ten sposób handlowano wolnymi mocami obwodów telekomunikacyjnych, a konsorcja dostawców i producentów z branży lotniczej, samochodowej itp. otworzyły portale internetowe w tym samym zamiarze. Usługi flot transportowych są również oczywistym obszarem, w którym można handlować wolnymi zdolnościami produkcyjnymi. Te aranżacje są jednak tylko tak naprawdę na wpół publiczne. Rynek konsumencki, który na ogół obejmuje prostsze zakupy bez skomplikowanych umów, otworzył się szybciej, a aukcje internetowe odniosły spory sukces. Technologia ich obsługi nie jest szczególnie skomplikowana.