Wymagania techniczne popularnych aplikacji pakietowych w informatyzacji przedsiębiorstwa

Organizacje oceniające przydatność do swych celów zintegrowanych aplikacji pakietowych, takich jak R/3 firmy SAP, Oracle Applications (firmy Oracle) czy Triton zwany Baan od wersji 4.0 (firmy Baan) mają podwójnie skomplikowane zadanie. Pierwsze i najważniejsze, muszą zrozumieć jak aplikacja pasuje i jak może być adaptowana do funkcji gospodarczych przedsiębiorstwa. Oznacza to zrozumienie jak program realizuje procesy produkcyjne i finansowe, i czy można zmienić tę realizację, tak aby pasowała do potrzeb przedsiębiorstwa.

Zadanie to jest trudne. W pakietach istnieje wiele podobnych funkcji, ale nie ma zupełnej zgodności między nimi, nie wszystkie pakiety są takie same. Na przykład moduł kadrowy jest dostępny w pakietach R/3 i Oracle, ale nie ma go w pakiecie Baan. Produkcja - najważniejszy program we wszystkich trzech pakietach - jest podzielony na kilka modułów o szerokim zakresie właściwości funkcjonalnych w R/3, ale jest pojedynczym modułem w pakietach Baan i Oracle. Bardziej szczegółowa analiza pokazuje, że istnieje ogromna rozbieżność właściwości funkcjonalnych i ich zakresie, nawet tam gdzie zakresy te się pokrywają.

Różnice funkcjonalne należy rozważać we wczesnym okresie oceny przydatności pakietów, ale drugi zestaw problemów często ujawnia się dopiero znacznie później. Dotyczą one infrastruktury technicznej: pośredniej warstwy oprogramowania komunikacyjnego aplikacji (middleware), dostępu do baz danych, wymienności danych, strategii narzędziowych i in. Instalacja pakietu Baan, Oracle czy R/3 oznacza zastosowanie w całym przedsiębiorstwie specyficznej dla niego technologii. Może to oznaczać zmianę korporacyjnego systemu bazy danych lub standardu pakietu komunikacyjnego, aby dostosować je do wymagań pakietu. W innych przypadkach oznacza to przyjęcie zestawów narzędziowych pakietu do tworzenia aplikacji w przedsiębiorstwie. W większości przypadków każdy pakiet wywołuje konieczność dostosowania infrastruktury technicznej do swoich wymagań.

Dla organizacji pragnących przejść na nową technologię w sposób możliwie łagodny lub pragnących zintegrować ją z istniejącymi w firmie aplikacjami klient/serwer, dobre zrozumienie wymagań związanych ze zmianą infrastruktury oznaczać może różnicę między udanym wdrożeniem a koszmarem.

Poniżej analizujemy trzy najważniejsze problemy techniczne: dostęp do baz danych, middleware i zestawy narzędziowe pakietów aplikacji.

Dostęp do baz danych

Zrozumienie sposobu dostępu do baz danych przez aplikację pakietową ma szczególnie ważne znaczenie dla organizacji stosujących różne systemy zarządzania relacyjnymi bazami danych.

Sposób dostępu do bazy danych stanowi główny wyróżnik tych trzech produktów. Każdy z pakietów zapewnia otwartą strategię dostępu do baz danych i pozwala na korzystanie z różnych systemów zarządzania bazami. Jednakże Oracle wspiera w trybie rodzimym jedynie własny system zarządzania bazami danych. Natomiast Baan i SAP - dwóch liderów rynku baz danych: Oracle'a i Informixa; nie wspierają one systemu Sybase, gdyż ta baza nie pozwala na blokowanie tabel na poziomie rekordów, zaś zarówno Baan, jak i SAP zostały zaprojektowane do takiego wymagania. Z drugiej strony, Baan i SAP ogłosiły niedawno wsparcie dla bazy Microsoft SQL Server, chociaż jest mało prawdopodobne, aby baza ta była w stanie obsługiwać dużą liczbę jednoczesnych użytkowników.

Ważne kryterium wyboru związane jest ze wsparciem wielu systemów baz danych, realizowanym inaczej w każdym pakiecie. Baan jest najbardziej otwarty: pojedynczy moduł może korzystać z wielu systemów baz danych. (W zasadzie nie ma technicznych ograniczeń, co do liczby systemów baz danych, ale praktyczne problemy z zarządzaniem nimi wykluczają użycie więcej niż trzech baz). SAP R/3 dopuszcza jednoczesne korzystanie z wielu systemów baz danych, ale nie z pojedynczego modułu. W przypadku pakietu Oracle, do innych baz niż oracle'owe trzeba dostawać się za pośrednictwem bram (gateway). Jest to rozwiązanie limitujące znacznie szybkość dostępu.

Brak swobody w dostępie do różnych systemów baz danych nie jest wcale najgorszy: niezależność od systemu baz danych oznacza możliwość dokonywania wyboru, a to z kolei oznacza dodatkową złożoność systemu. Użytkownik musi rozważyć: czy woli zachować swobodę wyboru za cenę wyższych kosztów implementacji i rozwoju pakietów (SAP i Baan), czy zrezygnować z niezależności za cenę ściślejszej integracji i łatwości uruchomienia pakietu (Oracle).