Stary dobry znajomy: Oracle forms
Historia narzędzi Oracle Forms sięga późnych lat 80. i choć ich popularność wyraźnie spadła wraz z rozpowszechnieniem się Internetu, wciąż wiele aplikacji bazuje na tym rozwiązaniu. Pod wieloma względami dostępna obecnie wersja 11g niewiele przypomina te sprzed 20 lat, z drugiej jednak strony, mimo wielu dużych zmian, wciąż pełni tę samą funkcję: pozwala szybko tworzyć aplikacje bazodanowe. W tym artykule przyjrzymy się przyszłości samej technologii oraz zastanowimy się, kiedy warto się z nią rozstać i jak to zrobić.
{loadposition IT_Dzial]
Przyszłość technologii Forms
Na początek sprawa najważniejsza: Forms jest na rynku od 20 lat i prędko nie zniknie. Na rynku można usłyszeć wiele opinii i plotek na temat końca Formsów, ale oficjalny dokument mówi jasno (cytuję w oryginale, dla podkreślenia autentyczności):
Oracle has no plan to desupport these products. Furthermore, new version of Oracle Forms, Oracle Reports will continue to be released as part of Oracle Fusion Middleware and Oracle Forms 11g and Oracle Reports 11g are components of Oracle Fusion Middleware 11g.
Zadowoleni użytkownicy Formsów nie mają zatem powodów do obaw – mogą dalej korzystać z tej technologii i rozwijać swoje aplikacje korzystając z nowych funkcjonalności. Dla pozostałych, w drugiej części artykułu omówimy możliwe sposoby migracji z Forms do innych rozwiązań.
Nowości w Forms 11g
Na pierwszy rzut oka największą zmianą w Forms 11g jest zmiana używanego serwera aplikacji Java z OC4J na WebLogic. Wpływ tej zmiany na tworzenie i działanie aplikacji Formsowych jest jednak minimalny, ponieważ główny komponent uruchomieniowy, Forms Server, jest napisany w C/C++, a zatem w ogóle nie jest uruchamiany w kontenerze Java. Zmigrowane zostały jedynie procesy Forms Listener Servlet i Forms Servlet, które są niewielkimi komponentami napisanymi w Javie. Zmiany odczują zatem głównie administratorzy, którzy będą musieli nauczyć się zarządzania serwerem WebLogic.
Znacznie ciekawsze, choć nie tak widoczne, są dwie nowe funkcjonalności: wsparcie dla bazodanowych kolejek AQ (Advanced Queuing) oraz wsparcie dwukierunkowej komunikacji z JavaScriptem znajdującym się na stronie z formatką. Wsparcie dla AQ umożliwia wywoływanie kodu Forms z zewnątrz – np. z procesu BPEL. Po odczytaniu komunikatu z kolejki, serwer Forms wywołuje nowy trigger WHEN-EVENT-RAISED, który obsługuje zdarzenie. Ponieważ Formsy działają w trybie żądanie-odpowiedź, pojawił się także nowy parametr MAX_EVENT_WAIT, który określa maksymalny czas od pojawienia się zdarzenia w kolejce, do jego obsłużenia. Komunikacja między formatką a JavaScriptem pozwala z kolei na wywoływanie zdarzeń z zewnątrz, ale na poziomie interfejsu użytkownika. Możemy zatem przygotować stronę, na której osadzona będzie formatka oraz dowolny inny kod HTML, który będzie wywoływał zdarzenia w formatce i na przykład przekazywał do formatki wartości pól, które użytkownik wypełnił poza formatką. Możliwa jest także komunikacja w drugą stronę – formatka (lub Forms trigger) może wywołać dowolny kod JavaScript, na przykład odświeżenie fragmentów strony znajdujących się obok formatki. Korzystając z tej możliwości można teoretycznie całkowicie ukryć przed użytkownikiem aplet Forms, przygotowując nowy interfejs użytkownika, który jednak wszystkie operacje będzie przekazywał do apletu w celu obsłużenia logiki biznesowej.
Opisane powyżej nowe funkcje ułatwiają integrowanie aplikacji Forms z bardziej nowoczesnymi technologiami oraz z narzędziami SOA – takimi, jak szyny usług i silniki procesów biznesowych. Choć od dawna możliwe jest wywoływanie kodu Java z poziomu Forms (poprzez Forms Java Importer), to nowe możliwości powodują, że rzadziej będzie to konieczne. Z drugiej strony 11g upraszcza tworzenie zaawansowanych rozszerzeń w Javie, gdy faktycznie są one potrzebne. Inne zmiany wprowadzone w Forms 11g, to przede wszystkim ulepszone mechanizmy diagnostyczne i narzędzia administracyjne.
Migrować, czy nie migrować
Istnieje przynajmniej kilka dobrych powodów, które mogą nas skłonić do odejścia od Formsów (większość z nich dotyczy także innych technologii poprzedniej generacji). Przede wszystkim na rynku jest coraz mniej osób programujących w Forms. Nie ma raczej co liczyć na absolwentów, czy samouków, a rywalizacja o doświadczonych programistów będzie się zaostrzać - tak, jak niegdyś o osoby znające COBOLa. Po drugie, choć Formsy przez lata ewoluowały wraz z całym światem IT, to jednak nie wpisują się idealnie we współczesne trendy komponentowych aplikacji webowych, czy architektury SOA (choć wersja 11g jest krokiem naprzód w tym zakresie). I chociaż bez problemu możemy z Forms wywoływać web services, a także udostępniać logikę biznesową aplikacji Forms jako usługę, to jednak Formsy od początku były tworzone jako narzędzie dla aplikacji bazodanowych. Jeśli zatem nasza aplikacja ma korzystać z różnych źródeł danych, komunikować się z wieloma innymi aplikacjami i integrować na poziomie interfejsu użytkownika, to prawdopodobnie Forms nie jest najlepszym wyborem.
Sposób migracji
Istnieją dwie zasadnicze ścieżki migracji: ewolucyjna i rewolucyjna. Pierwsza polega na integrowaniu Formsów z modułami napisanymi w innych technologiach i stopniowym przepisywaniu poszczególnych formatek. Druga, to całkowite odejście od Forms w jednym kroku. Ścieżka ewolucyjna pozwala oswoić się z nowym środowiskiem i przećwiczyć proces migracji na mniej krytycznych modułach aplikacji, zanim zabierzemy się za przepisywanie tych najważniejszych. Podejście rewolucyjne wymaga dobrej znajomości docelowego stosu technologicznego, oswojenia użytkowników z nowym środowiskiem oraz odpowiedniego podejścia do osób, które dotychczas rozwijały aplikację (przeszkolenie ich w zakresie nowych narzędzi lub znalezienie dla nich nowych zajęć, by nie stracić wiedzy zdobytej przez nich przez lata rozwoju i eksploatacji systemu). Jeśli nadal używamy Formsów w wersji klient-serwer, a chcemy przejść do środowiska webowego, to prawdopodobnie nie obejdzie się jednak bez rewolucji.
Kiedy nakreślimy już proces migracji, pozostaje pytanie: w jaki sposób przenosić poszczególne komponenty do nowego środowiska? Do wyboru mamy oczywiście migrację manualną, która jest niczym innym, jak napisaniem aplikacji od nowa. Podczas przepisywania możemy nie tylko zmienić technologię, ale również przemyśleć na nowo interfejs użytkownika i oczyścić aplikację z elementów, które nawarstwiły się przez lata i niepotrzebnie komplikowały implementację. Z drugiej strony trzeba się liczyć z tym, że pisząc wiele rzeczy od nowa, popełnimy nowe błędy, a prawdopodobnie także powielimy stare, które były już kiedyś rozwiązane.
Z pomocą przychodzą narzędzia automatyzujące migrację. Osoby liczące na całkowicie automatyczne przeniesienie aplikacji Forms, na przykład do Java EE, będą jednak rozczarowane. Żadne dostępne na rynku narzędzie nie podejmie za nas decyzji, czy określona funkcjonalność powinna być zaimplementowana jak dotychczas w PL/SQL, czy przeniesiona do warstwy aplikacji. Tym bardziej żadne narzędzie nie przepisze kodu PL/SQL do Javy. Narzędzia pomogą nam jednak stworzyć funkcjonalny prototyp nowej aplikacji, mogą z dużą dokładnością stworzyć nowy interfejs użytkownika zbliżony do poprzedniego, jak również wskażą miejsca, które wymagają ręcznej pracy.
Narzędzia wspierające
Na rynku dostępnych jest przynajmniej kilka narzędzi wspierających migrację z Forms do innych technologii. Tutaj chciałbym się skupić na dwóch, które dostarczane są przez Oracle. Po pierwsze, do dyspozycji mamy rozszerzenie środowiska JDeveloper o nazwie JHeadstart. JHeadstart potrafi na podstawie formatek stworzyć działającą aplikację Java EE wykorzystującą framework ADF, posiadającą interfejs użytkownika zaimplementowany w JSF (ADF Faces), ale zbliżony do oryginalnej aplikacji w zakresie rozłożenia elementów na stronie i nawigacji. Aplikacja taka ma także dostęp do bazy danych – podstawowe operacje odczytu, zapisu czy wyszukiwania danych powinny działać automatycznie, podobnie jak listy wartości i inne typowe elementy formatek. Logika biznesowa pozostaje jako kod PL/SQL, więc należy albo ręcznie przepisać ją do Javy (lub innego języka), albo wywoływać w niezmienionej postaci (potencjalnie wystawiając ją jako web service). Dalszy rozwój aplikacji może odbywać się w oparciu o dowolne narzędzia środowiska Java EE, choć w zakresie IDE zalecany jest JDeveloper (jako jedyny posiada specjalne wsparcie dla frameworku ADF). Nie przeszkadza to jednak używać także innych środowisk i frameworków. Co ważne, JHeadstart nie generuje żadnego kodu Java, a jedynie pliki XML, dzięki czemu nie trzeba utrzymywać generowanego automatycznie kodu (co zwykle jest dość trudne). JHeadstart jest także, a nawet przede wszystkim, narzędziem do wysokopoziomowego tworzenia aplikacji w oparciu o ADF. Koncepcyjnie można go porównać do narzędzia Designer ze świata Formsów, który również pozwala na podstawie schematu bazy danych, wysokopoziomowej definicji funkcjonalności oraz szablonów (stron, formularzy, zakładek, przycisków, etc.), wygenerować działającą aplikację. Możemy ją następnie dowolnie modyfikować w JDeveloperze, a nasze poprawki przenieść do szablonów JHeadstarta, by zostały uwzględnione przy następnej generacji. Oczywiście możemy także po wstępnej migracji JHeadstartem zrezygnować całkowicie z tego narzędzia i dalej rozwijać aplikację typowymi narzędziami ze świata Java EE. JHeadstart może ułatwić migrację do całkowicie nowego świata – technologii Java EE. Jeśli jednak chcemy pożegnać się z Formsami, ale pozostać w świecie baz danych i języka PL/SQL, to możemy skorzystać z narzędzia Application Express (APEX) – darmowego dodatku do bazy danych Oracle. APEX pozwala tworzyć aplikacje WWW bezpośrednio w bazie danych (nie wymaga serwera aplikacji, a jedynie serwera HTTP, który jest dołączony do bazy danych). APEX potrafi migrować aplikacje Forms (jak również MS Access i Excel) do bazy danych Oracle i udostępniać je przez WWW. Podobnie jak w przypadku JHeadstarta, migracja skomplikowanych formatek będzie wymagała ręcznej pracy, ale dzięki częściowej automatyzacji możemy wyraźnie skrócić czas migracji. Dalszy rozwój aplikacji odbywa się w tym przypadku poprzez edycję kodu PL/SQL z logiką biznesową oraz wykorzystanie narzędzia APEX w zakresie interfejsu użytkownika (generowany jest kod PL/SQL, który z kolei w czasie działania generuje HTML).
Podsumowanie
Oracle Forms zdobyły sobie przez lata wielu zagorzałych zwolenników. Z drugiej strony dynamiczny rozwój rynku i technologii internetowych powoduje, że nieliczne firmy decydują się na rozwijanie nowych aplikacji w tej technologii. Znacznie częściej słyszymy pytania o to, kiedy i w jaki sposób należałoby zrezygnować z Formsów w istniejących aplikacjach. Najkrótsza odpowiedź: pośpiechu nie ma, ale warto zastanowić się co zyskujemy, a co tracimy wybierając Formsy. Jak wiadomo, kiedy mamy tylko młotek, wszystko wygląda jak gwóźdź. Innymi słowy, im więcej narzędzi znamy, tym lepiej potrafimy rozwiązywać rozmaite problemy, które przed nami stoją.
Źródło: http://oracle-pl.blogspot.com/
Na początek sprawa najważniejsza: Forms jest na rynku od 20 lat i prędko nie zniknie. Na rynku można usłyszeć wiele opinii i plotek na temat końca Formsów, ale oficjalny dokument mówi jasno (cytuję w oryginale, dla podkreślenia autentyczności):
Oracle has no plan to desupport these products. Furthermore, new version of Oracle Forms, Oracle Reports will continue to be released as part of Oracle Fusion Middleware and Oracle Forms 11g and Oracle Reports 11g are components of Oracle Fusion Middleware 11g.
Zadowoleni użytkownicy Formsów nie mają zatem powodów do obaw – mogą dalej korzystać z tej technologii i rozwijać swoje aplikacje korzystając z nowych funkcjonalności. Dla pozostałych, w drugiej części artykułu omówimy możliwe sposoby migracji z Forms do innych rozwiązań.
Nowości w Forms 11g
Na pierwszy rzut oka największą zmianą w Forms 11g jest zmiana używanego serwera aplikacji Java z OC4J na WebLogic. Wpływ tej zmiany na tworzenie i działanie aplikacji Formsowych jest jednak minimalny, ponieważ główny komponent uruchomieniowy, Forms Server, jest napisany w C/C++, a zatem w ogóle nie jest uruchamiany w kontenerze Java. Zmigrowane zostały jedynie procesy Forms Listener Servlet i Forms Servlet, które są niewielkimi komponentami napisanymi w Javie. Zmiany odczują zatem głównie administratorzy, którzy będą musieli nauczyć się zarządzania serwerem WebLogic.
Znacznie ciekawsze, choć nie tak widoczne, są dwie nowe funkcjonalności: wsparcie dla bazodanowych kolejek AQ (Advanced Queuing) oraz wsparcie dwukierunkowej komunikacji z JavaScriptem znajdującym się na stronie z formatką. Wsparcie dla AQ umożliwia wywoływanie kodu Forms z zewnątrz – np. z procesu BPEL. Po odczytaniu komunikatu z kolejki, serwer Forms wywołuje nowy trigger WHEN-EVENT-RAISED, który obsługuje zdarzenie. Ponieważ Formsy działają w trybie żądanie-odpowiedź, pojawił się także nowy parametr MAX_EVENT_WAIT, który określa maksymalny czas od pojawienia się zdarzenia w kolejce, do jego obsłużenia. Komunikacja między formatką a JavaScriptem pozwala z kolei na wywoływanie zdarzeń z zewnątrz, ale na poziomie interfejsu użytkownika. Możemy zatem przygotować stronę, na której osadzona będzie formatka oraz dowolny inny kod HTML, który będzie wywoływał zdarzenia w formatce i na przykład przekazywał do formatki wartości pól, które użytkownik wypełnił poza formatką. Możliwa jest także komunikacja w drugą stronę – formatka (lub Forms trigger) może wywołać dowolny kod JavaScript, na przykład odświeżenie fragmentów strony znajdujących się obok formatki. Korzystając z tej możliwości można teoretycznie całkowicie ukryć przed użytkownikiem aplet Forms, przygotowując nowy interfejs użytkownika, który jednak wszystkie operacje będzie przekazywał do apletu w celu obsłużenia logiki biznesowej.
Opisane powyżej nowe funkcje ułatwiają integrowanie aplikacji Forms z bardziej nowoczesnymi technologiami oraz z narzędziami SOA – takimi, jak szyny usług i silniki procesów biznesowych. Choć od dawna możliwe jest wywoływanie kodu Java z poziomu Forms (poprzez Forms Java Importer), to nowe możliwości powodują, że rzadziej będzie to konieczne. Z drugiej strony 11g upraszcza tworzenie zaawansowanych rozszerzeń w Javie, gdy faktycznie są one potrzebne. Inne zmiany wprowadzone w Forms 11g, to przede wszystkim ulepszone mechanizmy diagnostyczne i narzędzia administracyjne.
Migrować, czy nie migrować
Istnieje przynajmniej kilka dobrych powodów, które mogą nas skłonić do odejścia od Formsów (większość z nich dotyczy także innych technologii poprzedniej generacji). Przede wszystkim na rynku jest coraz mniej osób programujących w Forms. Nie ma raczej co liczyć na absolwentów, czy samouków, a rywalizacja o doświadczonych programistów będzie się zaostrzać - tak, jak niegdyś o osoby znające COBOLa. Po drugie, choć Formsy przez lata ewoluowały wraz z całym światem IT, to jednak nie wpisują się idealnie we współczesne trendy komponentowych aplikacji webowych, czy architektury SOA (choć wersja 11g jest krokiem naprzód w tym zakresie). I chociaż bez problemu możemy z Forms wywoływać web services, a także udostępniać logikę biznesową aplikacji Forms jako usługę, to jednak Formsy od początku były tworzone jako narzędzie dla aplikacji bazodanowych. Jeśli zatem nasza aplikacja ma korzystać z różnych źródeł danych, komunikować się z wieloma innymi aplikacjami i integrować na poziomie interfejsu użytkownika, to prawdopodobnie Forms nie jest najlepszym wyborem.
Sposób migracji
Istnieją dwie zasadnicze ścieżki migracji: ewolucyjna i rewolucyjna. Pierwsza polega na integrowaniu Formsów z modułami napisanymi w innych technologiach i stopniowym przepisywaniu poszczególnych formatek. Druga, to całkowite odejście od Forms w jednym kroku. Ścieżka ewolucyjna pozwala oswoić się z nowym środowiskiem i przećwiczyć proces migracji na mniej krytycznych modułach aplikacji, zanim zabierzemy się za przepisywanie tych najważniejszych. Podejście rewolucyjne wymaga dobrej znajomości docelowego stosu technologicznego, oswojenia użytkowników z nowym środowiskiem oraz odpowiedniego podejścia do osób, które dotychczas rozwijały aplikację (przeszkolenie ich w zakresie nowych narzędzi lub znalezienie dla nich nowych zajęć, by nie stracić wiedzy zdobytej przez nich przez lata rozwoju i eksploatacji systemu). Jeśli nadal używamy Formsów w wersji klient-serwer, a chcemy przejść do środowiska webowego, to prawdopodobnie nie obejdzie się jednak bez rewolucji.
Kiedy nakreślimy już proces migracji, pozostaje pytanie: w jaki sposób przenosić poszczególne komponenty do nowego środowiska? Do wyboru mamy oczywiście migrację manualną, która jest niczym innym, jak napisaniem aplikacji od nowa. Podczas przepisywania możemy nie tylko zmienić technologię, ale również przemyśleć na nowo interfejs użytkownika i oczyścić aplikację z elementów, które nawarstwiły się przez lata i niepotrzebnie komplikowały implementację. Z drugiej strony trzeba się liczyć z tym, że pisząc wiele rzeczy od nowa, popełnimy nowe błędy, a prawdopodobnie także powielimy stare, które były już kiedyś rozwiązane.
Z pomocą przychodzą narzędzia automatyzujące migrację. Osoby liczące na całkowicie automatyczne przeniesienie aplikacji Forms, na przykład do Java EE, będą jednak rozczarowane. Żadne dostępne na rynku narzędzie nie podejmie za nas decyzji, czy określona funkcjonalność powinna być zaimplementowana jak dotychczas w PL/SQL, czy przeniesiona do warstwy aplikacji. Tym bardziej żadne narzędzie nie przepisze kodu PL/SQL do Javy. Narzędzia pomogą nam jednak stworzyć funkcjonalny prototyp nowej aplikacji, mogą z dużą dokładnością stworzyć nowy interfejs użytkownika zbliżony do poprzedniego, jak również wskażą miejsca, które wymagają ręcznej pracy.
Narzędzia wspierające
Na rynku dostępnych jest przynajmniej kilka narzędzi wspierających migrację z Forms do innych technologii. Tutaj chciałbym się skupić na dwóch, które dostarczane są przez Oracle. Po pierwsze, do dyspozycji mamy rozszerzenie środowiska JDeveloper o nazwie JHeadstart. JHeadstart potrafi na podstawie formatek stworzyć działającą aplikację Java EE wykorzystującą framework ADF, posiadającą interfejs użytkownika zaimplementowany w JSF (ADF Faces), ale zbliżony do oryginalnej aplikacji w zakresie rozłożenia elementów na stronie i nawigacji. Aplikacja taka ma także dostęp do bazy danych – podstawowe operacje odczytu, zapisu czy wyszukiwania danych powinny działać automatycznie, podobnie jak listy wartości i inne typowe elementy formatek. Logika biznesowa pozostaje jako kod PL/SQL, więc należy albo ręcznie przepisać ją do Javy (lub innego języka), albo wywoływać w niezmienionej postaci (potencjalnie wystawiając ją jako web service). Dalszy rozwój aplikacji może odbywać się w oparciu o dowolne narzędzia środowiska Java EE, choć w zakresie IDE zalecany jest JDeveloper (jako jedyny posiada specjalne wsparcie dla frameworku ADF). Nie przeszkadza to jednak używać także innych środowisk i frameworków. Co ważne, JHeadstart nie generuje żadnego kodu Java, a jedynie pliki XML, dzięki czemu nie trzeba utrzymywać generowanego automatycznie kodu (co zwykle jest dość trudne). JHeadstart jest także, a nawet przede wszystkim, narzędziem do wysokopoziomowego tworzenia aplikacji w oparciu o ADF. Koncepcyjnie można go porównać do narzędzia Designer ze świata Formsów, który również pozwala na podstawie schematu bazy danych, wysokopoziomowej definicji funkcjonalności oraz szablonów (stron, formularzy, zakładek, przycisków, etc.), wygenerować działającą aplikację. Możemy ją następnie dowolnie modyfikować w JDeveloperze, a nasze poprawki przenieść do szablonów JHeadstarta, by zostały uwzględnione przy następnej generacji. Oczywiście możemy także po wstępnej migracji JHeadstartem zrezygnować całkowicie z tego narzędzia i dalej rozwijać aplikację typowymi narzędziami ze świata Java EE. JHeadstart może ułatwić migrację do całkowicie nowego świata – technologii Java EE. Jeśli jednak chcemy pożegnać się z Formsami, ale pozostać w świecie baz danych i języka PL/SQL, to możemy skorzystać z narzędzia Application Express (APEX) – darmowego dodatku do bazy danych Oracle. APEX pozwala tworzyć aplikacje WWW bezpośrednio w bazie danych (nie wymaga serwera aplikacji, a jedynie serwera HTTP, który jest dołączony do bazy danych). APEX potrafi migrować aplikacje Forms (jak również MS Access i Excel) do bazy danych Oracle i udostępniać je przez WWW. Podobnie jak w przypadku JHeadstarta, migracja skomplikowanych formatek będzie wymagała ręcznej pracy, ale dzięki częściowej automatyzacji możemy wyraźnie skrócić czas migracji. Dalszy rozwój aplikacji odbywa się w tym przypadku poprzez edycję kodu PL/SQL z logiką biznesową oraz wykorzystanie narzędzia APEX w zakresie interfejsu użytkownika (generowany jest kod PL/SQL, który z kolei w czasie działania generuje HTML).
Podsumowanie
Oracle Forms zdobyły sobie przez lata wielu zagorzałych zwolenników. Z drugiej strony dynamiczny rozwój rynku i technologii internetowych powoduje, że nieliczne firmy decydują się na rozwijanie nowych aplikacji w tej technologii. Znacznie częściej słyszymy pytania o to, kiedy i w jaki sposób należałoby zrezygnować z Formsów w istniejących aplikacjach. Najkrótsza odpowiedź: pośpiechu nie ma, ale warto zastanowić się co zyskujemy, a co tracimy wybierając Formsy. Jak wiadomo, kiedy mamy tylko młotek, wszystko wygląda jak gwóźdź. Innymi słowy, im więcej narzędzi znamy, tym lepiej potrafimy rozwiązywać rozmaite problemy, które przed nami stoją.
Źródło: http://oracle-pl.blogspot.com/
Autor: Michał Kuratczyk
Najnowsze wiadomości
Customer-specific AI: dlaczego w 2026 roku to ona przesądza o realnym wpływie AI na biznes
W 2026 roku sztuczna inteligencja przestaje być ciekawostką technologiczną, a zaczyna być rozliczana z realnego wpływu na biznes. Organizacje oczekują dziś decyzji, którym można zaufać, procesów działających przewidywalnie oraz doświadczeń klientów, które są spójne w skali. W tym kontekście coraz większe znaczenie zyskuje customer-specific AI - podejście, w którym inteligencja jest osadzona w danych, procesach i regułach konkretnej firmy, a nie oparta na generycznych, uśrednionych modelach.
PROMAG S.A. rozpoczyna wdrożenie systemu ERP IFS Cloud we współpracy z L-Systems
PROMAG S.A., lider w obszarze intralogistyki, rozpoczął wdrożenie systemu ERP IFS Cloud, który ma wesprzeć dalszy rozwój firmy oraz integrację kluczowych procesów biznesowych. Projekt realizowany jest we współpracy z firmą L-Systems i obejmuje m.in. obszary finansów, produkcji, logistyki, projektów oraz serwisu, odpowiadając na rosnącą skalę i złożoność realizowanych przedsięwzięć.
SkyAlyne stawia na IFS dla utrzymania floty RCAF
SkyAlyne, główny wykonawca programu Future Aircrew Training (FAcT), wybrał IFS Cloud for Aviation Maintenance jako cyfrową platformę do obsługi technicznej lotnictwa i zarządzania majątkiem. Wdrożenie ma zapewnić wgląd w czasie rzeczywistym w utrzymanie floty, zasoby i zgodność, ograniczyć przestoje oraz zwiększyć dostępność samolotów szkoleniowych RCAF w skali całego kraju. To ważny krok w modernizacji kanadyjskiego systemu szkolenia załóg lotniczych.
Wykorzystanie AI w firmach rośnie, ale wolniej, niż oczekiwano. Towarzyszy temu sporo rozczarowań
Wykorzystanie sztucznej inteligencji w firmach rośnie, ale tempo realnych wdrożeń pozostaje znacznie wolniejsze od wcześniejszych oczekiwań rynku. Dane pokazują, że z rozwiązań AI korzysta dziś wciąż niewiele przedsiębiorstw, a menedżerowie coraz częściej wskazują na bariery regulacyjne, koszty oraz brak powtarzalnych efektów biznesowych. W praktyce technologia jest testowana głównie w wybranych obszarach, a kluczowe decyzje nadal pozostają po stronie człowieka. Również w firmach, które wdrożyły AI, nierzadko towarzyszą temu rozczarowania.
Europejski przemysł cyfryzuje się zbyt wolno – ERP, chmura i AI stają się koniecznością
Europejski przemysł średniej wielkości wie, że cyfryzacja jest koniecznością, ale wciąż nie nadąża za tempem zmian. Ponad 60% firm ocenia swoje postępy w transformacji cyfrowej jako zbyt wolne, mimo rosnącej presji konkurencyjnej, regulacyjnej i kosztowej. Raport Forterro pokazuje wyraźną lukę między świadomością potrzeby inwestycji w chmurę, ERP i AI a realną zdolnością do ich wdrożenia – ograniczaną przez braki kompetencyjne, budżety i gotowość organizacyjną.
Europejski przemysł średniej wielkości wie, że cyfryzacja jest koniecznością, ale wciąż nie nadąża za tempem zmian. Ponad 60% firm ocenia swoje postępy w transformacji cyfrowej jako zbyt wolne, mimo rosnącej presji konkurencyjnej, regulacyjnej i kosztowej. Raport Forterro pokazuje wyraźną lukę między świadomością potrzeby inwestycji w chmurę, ERP i AI a realną zdolnością do ich wdrożenia – ograniczaną przez braki kompetencyjne, budżety i gotowość organizacyjną.
Najnowsze artykuły
5 pułapek zarządzania zmianą, które mogą wykoleić transformację cyfrową i wdrożenie ERP
Dlaczego jedne wdrożenia ERP dowożą korzyści, a inne kończą się frustracją, obejściami w Excelu i spadkiem zaufania do systemu? Najczęściej decyduje nie technologia, lecz to, jak organizacja prowadzi zmianę: czy liderzy biorą odpowiedzialność za decyzje czy tempo jest dopasowane do zdolności absorpcji oraz czy ludzie dostają klarowność ról i realne kompetencje. Do tego dochodzi pytanie: co po go-live - stabilizacja czy chaos w firmie? Poniżej znajdziesz 5 pułapek, które najczęściej wykolejają transformację i praktyczne sposoby, jak im zapobiec.
SAP vs Oracle vs Microsoft: jak naprawdę wygląda chmura i sztuczna inteligencja w ERP
Wybór systemu ERP w erze chmury i sztucznej inteligencji to decyzja, która determinuje sposób działania organizacji na lata — a często także jej zdolność do skalowania, adaptacji i realnej transformacji cyfrowej. SAP, Oracle i Microsoft oferują dziś rozwiązania, które na pierwszy rzut oka wyglądają podobnie, lecz w praktyce reprezentują zupełnie odmienne podejścia do chmury, AI i zarządzania zmianą. Ten artykuł pokazuje, gdzie kończą się deklaracje, a zaczynają realne konsekwencje biznesowe wyboru ERP.
Transformacja cyfrowa z perspektywy CFO: 5 rzeczy, które przesądzają o sukcesie (albo o kosztownej porażce)
Transformacja cyfrowa w finansach często zaczyna się od pytania o ERP, ale w praktyce rzadko sprowadza się wyłącznie do wyboru systemu. Dla CFO kluczowe jest nie tylko „czy robimy pełną wymianę ERP”, lecz także jak policzyć ryzyko operacyjne po uruchomieniu, ocenić wpływ modelu chmurowego na koszty OPEX oraz utrzymać audytowalność i kontrolę wewnętrzną w nowym modelu działania firmy.
Agentic AI rewolucjonizuje HR i doświadczenia pracowników
Agentic AI zmienia HR: zamiast odpowiadać na pytania, samodzielnie realizuje zadania, koordynuje procesy i podejmuje decyzje zgodnie z polityką firmy. To przełom porównywalny z transformacją CRM – teraz dotyczy doświadczenia pracownika. Zyskują HR managerowie, CIO i CEO: mniej operacji, więcej strategii. W artykule wyjaśniamy, jak ta technologia redefiniuje rolę HR i daje organizacjom przewagę, której nie da się łatwo nadrobić.
Composable ERP: Przewodnik po nowoczesnej architekturze biznesowej
Czy Twój system ERP nadąża za tempem zmian rynkowych, czy stał się cyfrową kotwicą hamującą rozwój? W dobie nieciągłości biznesowej tradycyjne monolity ustępują miejsca elastycznej architekturze Composable ERP. To rewolucyjne podejście pozwala budować środowisko IT z niezależnych modułów (PBC) niczym z klocków, zapewniając zwinność nieosiągalną dla systemów z przeszłości. W tym raporcie odkryjesz, jak uniknąć pułapki długu technologicznego, poznasz strategie liderów rynku (od SAP po MACH Alliance) i wyciągniesz lekcje z kosztownych błędów gigantów takich jak Ulta Beauty. To Twój strategiczny przewodnik po transformacji z cyfrowego "betonu" w adaptacyjną "plastelinę".
Wykorzystanie AI w firmach rośnie, ale wolniej, niż oczekiwano. Towarzyszy temu sporo rozczarowań
Wykorzystanie sztucznej inteligencji w firmach rośnie, ale tempo realnych wdrożeń pozostaje znaczni… / Czytaj więcej
Vertiv Frontiers: 5 trendów, które przeprojektują centra danych pod „fabryki AI”
Centra danych wchodzą w erę „fabryk AI”, gdzie o przewadze nie decyduje już sama skala, lecz zdolno… / Czytaj więcej
Cyberbezpieczeństwo 2026. 6 trendów, które wymuszą nowe podejście do AI, danych i tożsamości
Rok 2026 zapowiada się jako moment przełomu w świecie cyfrowego bezpieczeństwa. W obliczu dynamiczn… / Czytaj więcej
Jurysdykcja danych w chmurze: dlaczego polskie firmy coraz częściej wybierają „gdzie leżą” ich system
Jurysdykcja danych przestała być detalem w umowach chmurowych – dziś decyduje o zgodności, bezpiecz… / Czytaj więcej
Tylko 7% firm w Europie wykorzystuje w pełni potencjał AI
72% firm w regionie EMEA uznaje rozwój narzędzi bazujących na sztucznej inteligencji za priorytet s… / Czytaj więcej
Chmura publiczna w Unii Europejskiej – między innowacją a odpowiedzialnością za dane
Transformacja cyfrowa w Europie coraz mocniej opiera się na chmurze publicznej, która stała się fun… / Czytaj więcej
