Kotły, turbiny i klawiatury
-
- Dorota Konowrocka,
- 16.12.2002
Ciepły strumień gotówki
Efektem wdrożenia systemu informatycznego, o ile można to ocenić zaledwie po roku działania systemu, jest lepsze wykorzystanie finansowych możliwości elektrociepłowni. Produkcja energii elektrycznej i ciepłej wody ma w elektrociepłowni charakter sezonowy, podobnie sezonowy charakter mają jej przychody. W sezonie jesienno-zimowym elektrociepłownia pracuje w pełnym tego słowa znaczeniu - pełną parą - i zarabia pieniądze, które poza sezonem są przeznaczane na prace remontowe. W takiej sytuacji szczególnie istotne jest zarządzanie nadwyżką gotówki poprzez odpowiednie jej lokowanie i planowanie jej przepływu w ciągu roku. Dlatego w module finansowym znajdują się mechanizmy umożliwiające rozróżnienie zasobów finansowych, które zostały "zarezerwowane" na pewne cele, od tych, które zostały realnie wydatkowane bądź muszą być wydatkowane w najbliższym okresie. Poprzednio zarezerwowanie pewnych zasobów przez dysponenta budżetu nie pozwalało na ich wykorzystanie, nawet jeśli termin płatności był dość odległy, a w tym czasie spodziewane były przychody.
Wdrożenie pociągnęło pewne istotne zmiany. O ile budżetowanie było prowadzone w elektrociepłowni od trzech lat, o tyle przed wdrożeniem stało się możliwe podrzucenie koledze z sąsiedniego działu budżetowego "kukułczego jaja" w postaci dodatkowych kosztów. Dziś zasady planowania i realizacji budżetu są określone dokładniej, chroniąc jednocześnie poszczególne działy przed "dorzucaniem" im kosztów nie przewidzianych przez nie wcześniej. Bardziej dostępna, aktualna i szczegółowa jest również informacja zarządcza. Teraz umożliwia menedżerom śledzenie bieżącej realizacji ich budżetów.
Parą można się poparzyć
Grzegorz Kawka ocenia dziś, że sporym błędem było rozpoczęcie wdrożenia od szkoleń użytkowników. Nie były one dostosowane do profilu elektrociepłowni i użytkownicy stracili sporo czasu na poznawaniu możliwości wykorzystania R/3, m.in. w przemyśle motoryzacyjnym. "Różnica między zakładem produkcji butów i fabryką samochodów jest niewielka, wykorzystywane są po prostu inne linie technologiczne. Różnica między zakładem produkcji czegokolwiek a elektrociepłownią jest natomiast ogromna! No, ale mądrzy jesteśmy dziś, wówczas nie mieliśmy odpowiedniego doświadczenia" - ocenia Grzegorz Kawka. Tempo szkoleń było dość szybkie, użytkownicy nie znali systemu, obawiali się więc nauki na systemie testowym, który zresztą niewiele miał wspólnego z profilem ich zakładu. I oczywiście, kiedy wdrożenie zostało już zakończone, trudno było wykorzystać nabytą kiedyś, może pozornie, wiedzę. Szkolenia przedstawiły bowiem jedynie "filozofię systemu", cokolwiek to określenie mogłoby oznaczać. Bardziej przydałyby się na zupełnie innym etapie - po zakończeniu wdrożenia, kiedy to użytkownicy powinni zacząć efektywnie wykorzystywać opracowany przez zespół projektowy system. "Postawiliśmy na stronę merytoryczną systemu, a więc jego architekturę i odwzorowanie w systemie rozmaitych funkcji zakładu i stworzenie możliwości analitycznych, a może trochę za mało myśleliśmy o użytkownikach, od których ostatecznie będzie zależeć efektywność jego wykorzystania" - twierdzi Grzegorz Kawka.
Grzegorz Kawka przyznaje, że większą uwagę zwróciłby również na etap analizy i uszczegółowienia zakresu wdrożenia. "Na etapie precyzowania wymagań wobec poszczególnych modułów dobrze jest zejść do poziomu jak największej szczegółowości. Później zwykle okazuje się bowiem, że w praktyce szczegółowe rozwiązania w jednym module mają znaczący wpływ na kształt drugiego, zmieniając czasem całkowicie jego projekt na poziomie bardziej ogólnym. Innymi słowy, trzeba dopracować kształt rozwiązania w najdrobniejszych szczegółach i uwzględnić w projekcie wszystkie wynikające z tego konsekwencje, nie licząc na to, że pewne szczegóły dopracuje się w praktyce, ponieważ mają one zazwyczaj wpływ na wiele podstawowych założeń" - zaznacza Grzegorz Kawka. Większy nacisk powinien też być położony na integrację i zapewnienie zgodności poszczególnych rozwiązań, aby osiągnąć zgodność danych w całym systemie.
Istota w planowaniu
Najważniejszym systemem informatycznym poza mySAP.com jest Contronics S sterujący pracą bloków energetycznych, czyli swoistego centrum dowodzenia pracą turbin, kotłów i innych maszyn działających w elektrociepłowni. Niektóre informacje pochodzące z tego systemu są wykorzystywane w raportach sporządzanych na potrzeby zarządu elektrociepłowni. Część informacji będzie wykorzystywana we wdrażanym obecnie module planowania (SEM). Chodzi zwłaszcza o informacje o wielkości produkcji energii i ciepła oraz ilości spalonego węgla. Istotą modułu planowania jest możliwość jego zastosowania w układaniu planu taryfowego na kolejny rok. Ustala się go z rocznym wyprzedzeniem na podstawie wytycznych URE, zgodnie z którymi przedstawione w planie ceny muszą znaleźć odpowiednie uzasadnienie w kosztach ponoszonych przez elektrociepłownię. Problemem podstawowym jest więc rozpoznanie i podział kosztów, w szczególności na koszty stałe i zmienne. Z rocznym wyprzedzeniem powinny być też znane takie elementy, jak plan remontów i ich spodziewane koszty, prognoza remontów awaryjnych, plan kosztów osobowych. Szczegółowe i trafne prognozowanie kosztów umożliwia osiągnięcie przez elektrociepłownię zysku satysfakcjonującego zarząd.
Co może SAP?
Leszek Gortal, zastępca kierownika projektu, specjalista ds. systemu informacji: Jak daleka jest integracja systemu, niech pokaże przykład "pilotki" (zawiadomienia o usterce), tworzonej przez pracowników Dyrekcji Produkcji. Jest ona powiązana z modułem Gospodarki Materiałowej i Gospodarki Remontowej poprzez zlecenie remontowe. Gdy do usunięcia usterki potrzebna jest część zamienna, specjalista generuje w systemie kwit "RW", pozwalający na pobranie właściwego materiału z magazynu. Po wydaniu materiału z magazynu, w zleceniu pojawiają się rzeczywiste koszty materiałów zużytych do naprawy. Dodając koszty usług, wiemy, ile kosztowało nas usunięcie usterki. Ruchy materiałowe "widać" w modułach Gospodarki Remontowej i Finansów. Pierwsze księgowania następują (oczywiście automatycznie) już po przyjęciu materiału do magazynu i są natychmiast widoczne w systemie.
Lidia Przychodzka, kierownik Wydziału Rachunkowości Zarządczej: Budżetowanie kosztów i inwestycji funkcjonowało w ECK od 1998 r., lecz w nieco inny sposób niż aktualnie. System budżetowania w elektrociepłowni jest oparty na schemacie organizacyjnym. Budżet roczny (w układzie miesięcznym) składa się z cząstkowych budżetów poszczególnych podmiotów budżetowych, ze wskazaniem imiennym osób odpowiedzialnych. Po każdym miesiącu poszczególne komórki organizacyjne dokonują analizy realizacji budżetu i składają stosowne wyjaśnienia w przypadku odchyleń. Przed wdrożeniem SAP taka analiza była możliwa dopiero w połowie następnego miesiąca, po sporządzeniu przez Wydział Rachunkowości Zarządczej raportów z realizacji budżetów i przekazaniu ich do odpowiednich komórek, odpowiedzialnych za poszczególne budżety. A czas płynął. W trzeciej dekadzie następnego miesiąca pojawiała się informacja, co było przyczyną odchyleń w realizacji budżetu w ubiegłym miesiącu. Najbardziej nękany był Wydział Rachunkowości, który musiał udostępniać dokumenty źródłowe w przypadku niejasności czy niezgodności.
Dzisiaj wygląda to nieco inaczej. Każda z osób odpowiedzialnych za wykonanie budżetów kosztów (lub osoba upoważniona) ma dostęp w systemie do swojego budżetu. Na bieżąco w ciągu miesiąca może śledzić jego realizację i reagować na ewentualne nieprawidłowości. Nie musi biegać do księgowości, by sprawdzić dokument, na podstawie którego zaksięgowano dany koszt. Dokument taki jest dostępny w SAP. Nie ma potrzeby robienia raportów i zużywania papieru, co z punktu widzenia dyscyplinowania kosztów nie jest bez znaczenia.
Trudny system kontra zwykli użytkownicy
Leszek Gortal: Wiele funkcjonalności mySAP.com powinien obsługiwać użytkownik końcowy, m.in. tworzenie zapytań (tzw. ABAP Querry). Obsługa i tworzenie zapytań nie są jednak proste i - niestety - przeciętny użytkownik nie jest na tyle zaawansowany, aby mógł samodzielnie tworzyć raporty, które go interesują.
Grzegorz Kawka, kierownik Wydziału Systemu Informacji: No właśnie, idea użytkowników-twórców systemu jest bardzo szczytna i piękna, ale ma jedną wadę. Należy ocenić, czy warta jest "skórka za wyprawkę". Jakie koszty będą związane ze szkoleniem użytkownika, np. w zakresie tworzenia raportów, rekonfiguracji, jeśli de facto wykorzystuje on system tylko operacyjnie? Taki użytkownik nie będzie ciągle pamiętał, jak się tworzy raporty. On chce z nich korzystać, zawarte w nich informacje są mu potrzebne do wykonywania jego pracy. Czy inwestować w jego umiejętności tworzenia raportów? Jak długo będzie posiadał te umiejętności? Czy nie lepiej zainwestować w dedykowanego pracownika, który będzie tworzył raporty i rekonfigurował system dla pewnej grupy pracowników? Natomiast bardzo ważna jest znajomość przez użytkownika końcowego możliwości systemu - ile można z systemu "wydusić" i czego nie można od niego żądać. I tu niezbędne są rozwijające wiedzę szkolenia merytoryczne. MySAP.com to potężny system. Musimy się jeszcze bardzo dużo nauczyć, poznać jego "zakamarki". Ten proces musi potrwać, i jest to prawdziwe wyzwanie. A tu jeszcze nam się gdzieniegdzie sypie, do tego zmienia się rynek, zmieniają się zasady, regulacje, deregulacje, różne umowy, próby lepszego rozwiązywania naszych problemów i realizacji wymagań klientów. To wszystko wpływa na pracę systemu i jego przemiany.
Procesy to nie wszystko
Grzegorz Kawka: Przygotowując się do przetargu, przygotowaliśmy analizę funkcjonalności firmy w oderwaniu od technologii czy konkretnego rozwiązania. Był to czysty model, trochę abstrakcyjny. Przeanalizowaliśmy ponad 200 procesów, wiele osób zostało zaangażowanych do opisu przedsiębiorstwa, co zresztą też było pewną strategią działania. Właśnie wtedy umożliwiliśmy bowiem wypowiedzenie się dużej grupie pracowników, co zaowocowało w okresie wdrożenia. Analiza procesów pozwoliła przygotować materiał do przetargu, na jej podstawie dokonaliśmy wyboru systemu. Czy jednak model może zostać w pełni, dokładnie odwzorowany w konkretnym systemie? Model "przetłumaczony" na język SAP odzwierciedla nasze potrzeby w mniejszym lub większym stopniu.
Paweł Kaliński, kierownik Wydziału Zarządzania Finansowego: Definiowanie procesów to jedna rzecz, a praca w systemie, który te procesy odwzorowuje, to druga. Opis systemu i system nie w każdym momencie się zazębiały. Z jednej strony system ma pewne ograniczenia, których nie można przeskoczyć, z drugiej, jest na tyle elastyczny, że można zrobić w nim więcej niż oczekiwaliśmy. W ciągu kilku dni musieliśmy przejść ze starego systemu na nowy. Nie mieliśmy pewności, czy system jest w 100% przygotowany do startu operacyjnego. I co się stało? Ano nie wszystkie procesy zostały dokładnie opisane. Wydawało się, że już znamy wszystkie elementy, np. ekranów, połączeń, definicje związane z dowolną operacją w systemie finansowo-księgowym. Rozpoczęliśmy działanie operacyjne i nagle zaczęło się okazywać, że w różnych miejscach występują "zachwiania" i potrzebne są korekty. To jest bardzo dobra metoda pracy, ale w fazie testowej systemu, a nie operacyjnej.
Refleksje po wdrożeniu
Lidia Przychodzka: Cały proces wdrażania SAP odbył się bardzo szybko i wiązał się z olbrzymim wysiłkiem. Wiele rzeczy nie zostało dopracowanych tak, jakbyśmy sobie tego życzyli. Teraz, z perspektywy czasu, sądzę, że tak trzeba było zrobić, kierując się prawem Parkinsona: "Im więcej mamy czasu na wykonanie jakiejś pracy, tym więcej czasu nam ona zabiera". Myślę, że zabrakło w całym procesie kogoś w rodzaju integratora, kogoś, kto znałby całą firmę, znałby sytuację w poszczególnych modułach i sprzęgał prace.
Grzegorz Kawka: Można powiedzieć, że brakowało nam doświadczenia w SAP-ie, a konsultantom - doświadczenia w energetyce. I to był problem, którego nie można było uniknąć. Ostatecznie dla obu stron było to pierwsze takie wdrożenie. Zostaliśmy rzuceni na głęboką wodę.
