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