Zrób Sobie Firmę

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ć.

Rozproszone grupy robocze mogą szeroko wykorzystywać e-mail jako tekstowy, ale raczej nieformalny sposób komunikowania się. Można oczywiście myśleć o e-mailu jako o zasadniczo szybkim sposobie wysłania listu lub o wysłaniu paczki, gdy dokument jest do niego „dołączony”. Przyjęcie tego podejścia może prowadzić do takich samych problemów, jak w przypadku poczty fizycznej. Co z tym zrobimy, kiedy to zdobędziemy? Jak go złożyć i jak wpasować w inne procesy, które prowadzą biznes? Czy eMail powinien być traktowany jako samodzielny byt, coś, co po prostu ląduje na czyimś biurku jako pragmatyczny komentarz, który można zignorować, wyrzucić lub zgubić? Może to prowadzić do wysokich kosztów administracyjnych i kosztów awarii. Ogólnie rzecz biorąc, prawdopodobnie prawdą jest stwierdzenie, że używanie poczty e-mail jako zwykłego mechanizmu zautomatyzowanego procesu jest złym pomysłem ze względu na jego luźną strukturę. (Zamiast tego użyj formularza.) Czasami jednak konieczne jest zajęcie się nieformalnie, a wtedy to, czego chcemy, to jakiś sposób na zintegrowanie nieformalnego i skoncentrowanego na osobie podejścia e-maila z resztą „bezosobowych” procesów biznesowych, takich jak fakturowanie, obsługa materiałów i tak dalej. Aby to zrobić, musimy traktować wiadomość e-mail jako część procesu biznesowego: „odpowiedzi klientów na marketingowe wiadomości e-mail”, „rozpatrywanie skarg klientów”, „zapytanie o zamówienie”, „uprawnienia obsługi wyjątków w celu zmiany projektu technicznego”, i tak dalej. Oznacza to, że musimy zrobić co najmniej trzy rzeczy: po pierwsze, przychodząca poczta e-mail musi być skierowana do kanału obsługi procesu, a nie do ogólnej skrzynki pocztowej danej osoby. Omawiamy mechanizmy, dzięki którym można to osiągnąć, w części 4, Serwis i wsparcie, gdzie przyglądamy się zintegrowanym centrom obsługi klienta. Po drugie, wiadomość e-mail musi być powiązana z odpowiednią inną dokumentacją. (Na przykład załączniki muszą być powiązane z wiadomością e-mail, z którą zostały dostarczone.) Po trzecie, wymóg e-mail musi uruchamiać proces biznesowy w sposób spójny z innymi częściami działania procesu, m.in. agenci muszą być automatycznie wzywani do odpowiedzi na wiadomość e-mail w wyznaczonym czasie. Z punktu widzenia technologii i interfejsu oznacza to, że systemy poczty e-mail zaczynają współdzielić wiele właściwości przeglądarek internetowych, interfejsów obsługi plików i oprogramowania do pracy grupowej zorientowanego na bazę danych. Integracja aplikacji globalnych i lokalnych jest również obszarem zainteresowania przy konstruowaniu oprogramowania do pracy grupowej dla przedsiębiorstw, które obejmuje nie tylko partnerów i dostawców, ale także naszych klientów. Portale korporacyjne integrujące dane zewnętrzne i wewnętrzne są jednym ze sposobów włączania klientów w ciągłe doskonalenie produktów i usług, a także obniżania kosztów funkcji help-desk. Wokół serwerów dyskusyjnych, które zarządzają segmentacją profili i listami mailingowymi, można budować moderowane grupy użytkowników, które omawiają problemy i rozwiązania poprzez wysyłanie wiadomości do wspólnej puli i wysyłanie selektywnie zgodnie z profilami zainteresowań odbiorców

Przestrzegaliśmy przed zbyt nieformalnym podejściem do pracy zespołowej i podkreślaliśmy potrzebę formalnych, pisemnych zapisów. Pisemne dokumenty mają oczywiście starożytne pochodzenie; pierwsze charakteryzowały się tym, że miały jedno autorstwo, jedną datę wydania, jednego mistrza i rezydowały w jednej bibliotece. Rozwój prasy drukarskiej zniósł ograniczenie jednej kopii, ale tylko w miejscu pochodzenia. Wygodne, tanie kopiowanie w punkcie odbioru pojawiło się dopiero w latach 60., wraz z rozwojem procesu Xerox. Przez kilka lat dokumenty pozostawały ograniczone pod względem ich dostępności i ruchu. Były głównie prywatne, dla wybranych osób na określonych stronach. Dopiero niedawno wszystkie te ograniczenia zostały zniesione dzięki technologii, a organizacje wciąż pogodziły się z konsekwencjami. Najważniejszym z nich jest pojawienie się skoncentrowanego na dokumentach spojrzenia na procesy współpracy. W ten sposób dokumentacja nie jest już statycznym zapisem, umocowanym tylko w jednym określonym czasie lub miejscu, ale raczej ewoluującym, dynamicznym mechanizmem rozpowszechniania historycznej, aktualnej i powstającej wiedzy korporacyjnej w sposób terminowy i spójny w całej organizacji. Twierdzi się, że dzięki takiemu podejściu ludzie mogą w ramach jednej operacji złożyć wszystkie swoje raporty, arkusze kalkulacyjne, formularze, wiadomości e-mail itp. w miejscu, w którym mogą być nie tylko widoczne dla innych, ale także poprawione, opatrzone adnotacjami, uzupełnione lub włączone do innej dokumentacji. Możemy na przykład wyobrazić sobie, że informacje o produkcie są zestawiane i nad którymi pracujemy wspólnie, w dokumentacji projektowej, raportach sprzedaży, usterkach i reklamacjach klientów, tak aby uzyskać zintegrowany obraz całej sprzedaży, produkcji, dostaw i funkcji wsparcia w organizacji. Jak pokazano na rysunku, samo udostępnienie centralnego repozytorium całej dokumentacji korporacyjnej nie wystarczy.

Konieczne jest również wykonanie szeregu funkcji kontrolnych nad tym. Przede wszystkim musi istnieć jakiś mechanizm kontroli wersji, który pilnuje numeracji wersji, przydzielania dat i utrzymywania historycznych kopii zapasowych poprzednich wersji. Jest to kluczowy wymóg, jeśli dokumenty mają podlegać ciągłym zmianom, zwłaszcza jeśli zaangażowanych jest więcej niż jeden autor. To natychmiast zwraca uwagę na potrzebę kontroli dostępu i uprawnień. Kto będzie mógł zobaczyć dokument; kto będzie mógł go modyfikować? Co właściwie rozumiemy przez „kto”? Moglibyśmy mieć na myśli osobę z nazwiska lub osobę identyfikowaną tylko na podstawie roli, którą odgrywa, lub zespołu, do którego należy. W przypadku dostępu do Internetu coraz częściej musimy uwzględniać lokalizację użytkownika jako kwestię kontroli dostępu. (Czy ograniczamy dostęp do znanych adresów IP? Czy zapewniamy dostęp mobilny chroniony hasłem?) Musimy również zwrócić uwagę na to, co zobaczy użytkownik, gdy uzyska dostęp do repozytorium. Dokumenty będą istniały w wielu formach: arkusze kalkulacyjne, e-maile, diagramy, raporty itp., a niektóre będą istniały jako sekcje modułowe, które można zestawiać na wiele sposobów, tworząc przewodnik szkoleniowy, instrukcję obsługi lub naprawy, broszurę sprzedażową . Musimy zapewnić szereg widoków zawartości repozytorium, który odpowiada potrzebom użytkownika, a także umożliwia wyszukiwanie i przeglądanie. Na koniec musimy przyznać, że myślenie o istnieniu jednego, scentralizowanego, fizycznego repozytorium wszystkich danych w wielu organizacjach nie jest już rozsądne. Zamiast tego rozproszone satelitarne bazy danych i serwery proxy będą przechowywać lokalne replikacje części lub wszystkich danych. Będą musiały zostać zsynchronizowane.  Produkty do pracy grupowej, które zapewniają solidne rozwiązania dla tych wymagań, są dostępne od jakiegoś czasu, przy czym dominującym przykładem są IBM (wcześniej Lotus) Notes. Notes obsługuje wszystkie opisane powyżej funkcje i zawiera system bezpieczeństwa oparty na szyfrowaniu kluczem publicznym w celu uwierzytelniania, kontroli dostępu i podpisów cyfrowych. W grę wchodzi uwierzytelnianie dwukierunkowe, w którym zarówno klienci, jak i serwery muszą potwierdzić swoją tożsamość przed rozpoczęciem dialogu. Dokumenty są jednoznacznie identyfikowane przez bazę danych, w której się znajdują, oraz numer w tej bazie danych. Są również opatrzone znacznikiem czasu z informacją o ostatnich zmianach. Istnieją złożone mechanizmy, które zapewniają synchronizację danych na wszystkich serwerach. Notatki zostały opracowane, zanim jeszcze zdano sobie sprawę z pełnego znaczenia Internetu, ale od tego czasu został rozszerzony wraz z rozwojem Domino, aby pasował do środowiska internetowego. Jednak nadal jest postrzegana przez niektórych miłośników Internetu jako podejście zorientowane na bazę danych, być może nawet przesadnie zaprojektowane. Jednym z problemów architektonicznych wynikających z modelu Internetu jest zakres, w jakim rzeczywiście wymagana jest replikacja danych. Skrajny pogląd jest taki, że wcale nie jest to konieczne: nie ma potrzeby śledzenia w oprogramowaniu do pracy grupowej kontroli wersji dokumentów; zamiast tego wszystko, co jest wymagane, to utrzymywanie listy adresów URL, pod którymi można znaleźć wersje. Nie wszystkie rozwiązania oprogramowania do pracy grupowej, które pojawiły się w ostatnich latach, wspierają ten mocny pogląd, ale mają zwykle lżejsze podejście do kontroli wersji niż te stosowane przez tradycjonalistów. Na koniec zwróć uwagę, że nie powiedzieliśmy nic o znajdowaniu odpowiednich informacji w tym potencjalnie ogromnym zbiorze danych korporacyjnych.

Istnieje wiele teorii (choć żadna nie do końca rozstrzygająca) na temat skuteczności tych wirtualnych spotkań w czasie rzeczywistym. Teraz może się okazać, że obecna wydajność usług audio i wideokonferencyjnych nie spełnia jeszcze standardów „prawdziwego” spotkania. Niemniej jednak oferują rozsądne, tanie rozwiązanie do wielu celów. Prawdą jest chyba stwierdzenie, że wzmacniają one współpracę, a nie budują zaufanie, ab initio. W związku z tym są bardzo satysfakcjonujące dla rozproszonych zespołów projektowych, które można uznać za posiadające przynajmniej minimalny zestaw wspólnych celów i celów. Na rutynowych tego typu spotkaniach dotyczących postępów w zupełności wystarcza dźwięk; wideo może być wymagane, gdy trzeba wytworzyć nieco więcej empatii lub gdy trzeba udostępnić informacje projektowe. W kontekście eBiznesu należy mieć świadomość, że w korzystaniu ze środowisk wirtualnych, które mają na celu budowanie zaufania i wspieranie empatii pomiędzy partnerami w wirtualnym przedsiębiorstwie, może pojawić się niebezpieczeństwo wynikające z ich skłonności do tworzenia nieformalnej atmosfery. Otwarte dyskusje i przyjazne uczucia są niezbędne, ale nie zawsze są ustrukturyzowane i nie zawsze łatwo przypomnieć sobie, co dokładnie zostało uzgodnione. Zaistnieje potrzeba sporządzania odpowiednich zapisów ze spotkań, zwykle w formie elektronicznej. Jednym z przykładów są negocjacje umowne. Innym przypadkiem są operacje call-center, w których integracja danych połączeń (czasu, wybieranego numeru itp.) może być automatycznie zintegrowana z notatkami do rozmowy wpisywanymi przez agenta call-center. To oczywiście oddaje tylko perspektywę minutnika na to, co się wydarzyło. Jedynym absolutnie dokładnym sposobem uchwycenia zdarzenia jest nagrywanie dźwięku (a może nawet wideo?). Chociaż niektóre instytucje finansowe robią to tam, gdzie w grę wchodzą transakcje o wysokiej wartości, nie należy lekceważyć tego. Utrzymanie urządzenia rejestrującego do obsługi całego ruchu z dużego call-center wiąże się ze znacznym nakładem pracy i staranną konserwacją. Prawdopodobna technologia byłaby czymś w rodzaju zestawu podstawowych magnetofonów kompaktowych, które nie są tak naprawdę znane ze swojej niezawodności ani jakości, ale są łatwe w administrowaniu i wygodne, ponieważ łatwo jest wrócić do wymaganej rozmowy. Rejestratory cyfrowe są bardziej niezawodne, ale drogie. Nagrywanie na dyskach jest jeszcze droższe i rzadko używane. W przypadku korzystania z sieciowej konferencji audio (patrz poniżej) możliwe jest zorganizowanie, za opłatą, przez dostawcę sieci wykonania nagrywania i transkrypcji. W przypadku spotkań biznesowych może być możliwe nagrywanie spotkania i przechowywanie taśm na wypadek przyszłego sporu. Tam, gdzie w grę wchodzą „fizyczne” spotkania, warunki nagrywania wymagają uważnego monitorowania – taśma zostanie użyta tylko wtedy, gdy dojdzie do poważnego sporu, a mowa, która stanie się niezrozumiała z powodu złych warunków, będzie tylko wzbudzać dalsze podejrzenia i złą wolę. Być może zaskakujące jest to, że łatwiej jest nagrywać wirtualne spotkanie: nagrywający i zaangażowane strony dzielą ten sam kanał wiadomości; jeśli słuchacze rozumieją mowę, to samo nagranie. Ponownie, maszyny nagrywające muszą być konserwowane i we wszystkich omawianych przypadkach trzeba mieć strategię ujawnienia istnienia nagrania i być przygotowanym na naturalne zahamowanie, które może się pojawić. Wreszcie prawie na pewno nie warto rozważać wykorzystania automatycznej konwersji mowy na tekst, jako sposobu tworzenia zapisu spotkania. Dosłowne transkrypcje spontanicznych dyskusji są niezwykle ubogie. (To, co faktycznie mówimy, bardzo różni się od tego, co zamierzamy powiedzieć, i często jest całkiem niezrozumiałe bez rejestrowania niuansów głosu, gestów i języka ciała.) Każdy automatyczny system rozpoznawania będzie gorszy. W każdym razie wątpliwe jest, czy istnieje jeszcze sprzęt do rozpoznawania głosu, który może zaoferować niezawodną konwersję na tekst w realistycznych warunkach spotkania, z nieograniczoną mową. Z tych wszystkich powodów dominującym medium do negocjowania krytycznych porozumień był tekst. Współczesna technologia pozwala teraz na szybsze tworzenie tego tekstu, co jest wygodą, ale nie jest zmianą jakościową. To, co również robi, i co prawdopodobnie ma jakościowy wpływ na sposób, w jaki pracujemy, to umożliwienie przekazywania tego tekstu i odzyskane znacznie szybciej, wygodniej i bezbłędnie. Jak widzimy w następnej sekcji, możemy spodziewać się nawet prawie jednoczesnego, wielokrotnego tworzenia. Wraz z istnieniem dokumentów, które można czytać i być może nad którymi można pracować w różnym czasie iw różnych miejscach, następuje eksplozja informacji, którą należy zarządzać i która umieszcza dokument w centrum procesu współpracy.

Choć nie tak nowy i modny jak wideokonferencje, audiokonferencje są dość mało wykorzystywanym, ale bardzo skutecznym sposobem prowadzenia rozproszonych spotkań. Jest dostarczana przez wiele firm telekomunikacyjnych jako usługa standardowa i bardzo łatwa w użyciu. Uczestnicy albo dzwonią na numer podany przez operatora telekomunikacyjnego, albo dzwonią do nich centralni operatorzy o określonej godzinie. Następnie przez cały czas trwania konferencji są połączeni przez mostek audiokonferencyjny, aby wszyscy mogli się słyszeć. Niektóre firmy telekomunikacyjne świadczą również usługi w zakresie nagrywania i/lub transkrypcji, które mogą być cenne, szczególnie gdy omawiane są umowy umowne. Uczestnicy mogą korzystać ze swoich zwykłych słuchawek telefonicznych lub mogą korzystać z zestawów głośnomówiących, w których może uczestniczyć kilka osób w jednym pomieszczeniu. Chociaż brakuje mowy ciała i ogólnej empatii wizualnej, dźwięk ma tę zaletę, że jakość mowy jest ogólnie dobra, nie jest wymagane żadne oświetlenie ani inne wyposażenie studyjne, a uczestnicy potrzebują tylko niedrogiego telefonu. (Możliwe jest również posiadanie uczestników z telefonów komórkowych, chociaż struktura spotkań może nie być kontrolowana i mogą wystąpić problemy z bezpieczeństwem i grzecznością podczas rozmów w miejscach publicznych.) Koszty takich spotkań są stosunkowo skromne, a rosnąca jakość telefonii IP jest bardzo niskie koszty, może sprawić, że będzie to jeszcze bardziej atrakcyjna propozycja. Telefonia IP, która jest oczywiście oparta na pakietach, jest łatwa do hostowania na komputerze i zależy prawie całkowicie od obciążenia zaangażowanych ścieżek transmisji, ze względu na jej jakość. Zwykle działa dobrze w sieci LAN i jest coraz częściej dostępny w korporacyjnych wirtualnych sieciach prywatnych, które można rozszerzyć na innych członków przedsiębiorstwa. Możemy nawet wyobrazić sobie, że interakcja głosowa na odległość stała się bardzo powszechna i całkiem naturalna, a nie skupiona wokół półformalnych spotkań: „połączenia” IP byłyby zawsze „włączone”, ale być może wyciszone, chyba że zostały celowo uruchomione. W ten sposób traktowalibyśmy dalekich kolegów tak, jakby znajdowali się w tym samym pokoju.

Wzrost wykorzystania wideokonferencji był raczej stały niż spektakularny. Nie jest jasne, dlaczego tak się stało. Niemniej jednak zaczyna przyciągać znaczną liczbę entuzjastów, a liczba ich będzie wzrastać w miarę rozwoju możliwości transmisji, obniżek cen i znajomości. Wideokonferencje możemy ogólnie podzielić na trzy osie

Jeśli chodzi o środowisko, decyzja zależy albo od skorzystania ze specjalistycznego studia, które zwykle może pomieścić większą liczbę osób, ma dobre warunki oświetleniowe i dźwiękowe, może wymagać rezerwacji i prawdopodobnie wymaga szybszej sieci, albo skorzystania z systemu stacjonarnego, co jest znacznie bardziej improwizowane i doraźne, pod względem liczby osób, które mogą wziąć udział (trzy to około maksimum na jednym końcu), jakości obrazu i dźwięku itp. Konferencje na biurku mogą być skuteczne między małymi, niepowiązanymi na przykład zespoły projektowe, szczególnie w połączeniu ze wspólnymi obiektami do obsługi dokumentów i tablic. (Możliwość „rysowania” myszą na obrazach udostępnianych w sieci.) Systemy takie jak te są dostępne jako standardowe oprogramowanie u większości głównych dostawców. Specjalistyczne studia, które często zawierają urządzenia do projekcji dokumentów, są lepsze na bardziej formalne okazje, ale oczywiście traci się możliwość zwołania spontanicznego spotkania, a konferencja nie staje się „normalnym” sposobem pracy. W praktyce wybór, który ma być używany, może być podyktowany dostępnością sieci w takim samym stopniu, jak cokolwiek innego. Usługi konferencyjne w studio są zazwyczaj oparte na łączach telekomunikacyjnych 2Mbit/s, co może być kosztowne. Konferencje na komputerze stacjonarnym, z ruchomymi obrazami o rozsądnej jakości, mogą być realizowane przez ISDN 64 kbit/s (patrz strona 28), chociaż często preferowane jest 128 kbit/s lub wyższe. Warunki te dotyczą pracy w szerokim obszarze. Jeśli możliwe jest działanie w sieci LAN, na przykład między ludźmi w parku naukowym, kampusie lub innym zbiorze lokalizacji, gdzie dane mogą być przesyłane z dużą prędkością, można użyć innych opcji, takich jak proste protokoły internetowe. Pomimo tego, że jest sprzedawany do użytku lokalnego lub rozległego, internetowe wideokonferencje przez sieć WAN zwykle zapewniają zatrważającą wydajność w większości obwodów, po prostu ze względu na duże opóźnienie sieci i niską przepustowość. Być może lepiej będzie użyć serii „fotografów”. Kolejna komplikacja pojawia się, jeśli konferencje mają obejmować więcej niż dwa miejsca. W takim przypadku istnieje potrzeba zapewnienia wielopunktowego mostka konferencyjnego, który łączy strumienie bitów z witryn, tak aby zaangażowane strony mogły widzieć innych uczestników w więcej niż jednej witrynie. Te mosty mogą znajdować się w witrynach firmowych, ale firmy telekomunikacyjne sprzedają również usługi pomostowe w swoich sieciach publicznych. Chociaż zwykle lepsza niż rozwiązania internetowe, jakość mostkowania telefonicznego, zwłaszcza opóźnienia między końcami, nie zawsze może być wystarczająco dobra, aby promować bezproblemową interakcję.