Przejdź do treści
Zapraszamy

Czytelników, rozmówców na forum, Autorów, Blogerów, Redaktorów,...

Przeczytaj o możliwościach korzystania z witryny i współpracy

Salon Business Dialog Klub Inspirations Klub Dialog CIO Business Meeting Point Kwintesencja Projekty Business Dialog

Czego się nauczyłem w pracy w korporacji?

luty 13, 2018 dodany przez Anonimowy

Maciek Młynarski pisząc posta w Grupie Renesans Organizacji, umieszczonej w domenie fi3 niejako wywołał mnie do tablicy. Dla tych, którzy nie mają dostępu do tej domeny (Fi3 to spółdzielnia, która powstała tutaj, w środowisku Business Dialog, więcej http://www.fi3.pl , a wymieniany Maciek jest jednym ze spółdzielców, jak i autor tego tekst - przyp. redakcji), cytuję Maćka: Historia SAP dziejąca się na naszych oczach pokazuje, że głęboka transformacja w marszu tak dużej firmy:

  • jest możliwa
  • jest możliwa bez kryzysu
  • udaje się

A transformacja ta polega na odejściu od starego paradygmatu COMMAND AND CONTROL w stronę nowych, lżejszych i bardziej zwinnych metod zarządzania czy współpracy z klientami.
I ten proof of concept niech służy Fabryce i ich klientom.
Potem pojawiła się dyskusja i … padło na mnie. Czuję się w obowiązku odpowiedzieć. Trzeba tu jasno wyłożyć sedno sprawy, o której napisał Maciek, bez wielkiej pompy i prezentacji – najlepiej z osobistej perspektywy. Dlatego nie stawiam dużych kwantyfikatorów „że zawsze, że wszędzie”. Mogę  tylko stwierdzić, „że ja…” – od dwudziestu lat doświadczam ciągłych zmian i nieustannie mam wrażenie, że najciekawsze jeszcze przede mną.
 
Pytanie, które przyszło do mnie przy pierwszej próbie napisania tego tekstu: czy firma, w której pracuję, jest korporacją? Sięgnąłem do https://en.wikipedia.org/wiki/SAP_SE i dowiedziałem się,  że według Wikipedii, jednak jest. Musiałem to sprawdzić, bo sam tak tego do tej pory tego nie czułem.
Czytam często różne opinie naszych forumowiczów na temat korporacji i związanej z nimi ciężkiej doli pracownika. A jednak, pomimo zaleceń doradców personalnych – mówiących o tym, że co najmniej co sześć lat warto zamienić swojego pracodawcę na innego - mnie zatrzymało tutaj coś na dłużej. Sam staram się zrozumieć, co to jest…  Może stało się tak dlatego, że średnio co pół roku mogę stawać do nowego wewnętrznego procesu rekrutacyjnego, po to by podjąć jakieś nowe wyzwanie? Wyzwanie to nie jest ograniczone krajem, kontynentem – i za każdym razem jest trochę inne. Można się po nim spodziewać zmiany roli oraz konieczności zdobycia nowych kompetencji. Dlatego nie wciąga mnie klasyczne wspinanie po „szczeblach korporacyjnej kariery”. Czuję za to przypływ adrenaliny, konieczność poradzenia sobie za każdym razem w nowym środowisku, potrzebę szybkiego zrozumienia tego, co się dzieje wokół, bez względu na to dokąd się udało w danym dniu dolecieć i gdzie wylądować. Można się dzięki temu częściej cieszyć z sukcesów, ale trzeba być również przygotowanym na osobiste porażki. Nic nie jest dane „na pewniaka”. Jednym słowem: trzeba być „twardym, jak w korporacji”.
 
Jak do tego doszło? Kiedy w latach dziewięćdziesiątych zacząłem pracę z systemami klasy Enterprise Resources Planning (ERP), moi przyjaciele mnie przestrzegali: „uważaj, lepiej zmień pracę. ERP to nie jest dobry sposób na dobre życie. To się szybko skończy” I mieli rację: czasy klasycznego, siermiężnego ERP już dawno minęły. Niech Was nie zmyli to, że ta nazwa nadal jest używana. Pomimo tego, że wizualnie niektóre elementy rozwiązań są podobne do tych z przed lat, to pod spodem działają już zupełnie inne silniki. Podobieństwo jest potrzebne, by zachować ciągłość, ale  na tych silnikach może jeszcze „jechać” tysiąc innych rozwiązań.
Oznacza to, że od tamtego czasu nastąpił organiczny wzrost oferty produktowej: z jednego pnia powstało wiele różnych produktów, ale w drugim aspekcie, poprzez wykorzystanie strategicznych akwizycji, dołączyły nowe, do tej pory samodzielnie istniejące linie produktowe. Aby to wszystko ogarnąć, trzeba się nie lada natrudzić, a i tak nie można być specjalistą od wszystkiego. Dlatego tak, jak w wielu sprawach w życiu, tak i we wnętrzu takiej firmy, nieustannie powraca pytanie: kim chcę być – i co chcę robić dalej? Możliwości jest wiele, dlatego zawsze warto o to pytać. Ja doszedłem do przekonania, że w takim świecie najlepiej jest być generalistą ze specjalizacją. A takim kimś jest architekt (nie wnikam na tym poziomie ogólności  w to, czy mówimy o rolach typu: Enterprise Architect, czy Solution Architect, czy o jakiejś innej…)   
 
Dla architekta kluczem do sukcesu jest integracja, wszak architektura jest sztuką łączenia wielu komponentów w jedną całość. Aby lepiej to zrozumieć, warto zauważyć, że w nowej architekturze rozwiązań informatycznych, procesy biznesowe „wyrywają się” swoim ERP-owym aplikacjom spod pełnej kontroli i wpływają na dobór nowych, innowacyjnych rozwiązań. Dzięki temu wzrosła rola analizy procesów biznesowych we wdrożeniach systemów standardowych (lub jak kto woli: powielarnych). Wzrosła też rola architektury rozwiązań, jako dyscypliny. Nie spełniły się obawy  początkowych krytyków systemów standardowych. Wskazywali oni wtedy na pewne teoretyczne ryzyko. Chodziło o to, że powszechne zastosowanie tego samego systemu standardowego może upodobnić do siebie wiele firm i i sugerować jeden sposób prowadzenia biznesu. Zanikłby wtedy czynnik konkurencyjności. Dlatego krytycy postulowali:  niech firmy używają różnych systemów, najlepiej uszytych na miarę. Jednak przepowiednia sprowadzenia wszystkich do wspólnego systemowego mianownika  nigdy się nie sprawdziła, a dzisiaj jest to praktycznie niemożliwe.
Nowoczesne systemy o standardowym rdzeniu są również otwarte na swój indywidualny rozwój osobno w każdej firmie. Dzięki dobrze przemyślanym rozwiązaniom rozwój ten nie zakłóca ogólnego standardu. W tym tkwi siła. Każde pojedyncze zastosowanie nowoczesnej technologii IT nie stoi w sprzeczności z zastosowaniem unikatowego modelu biznesowego, opartego na innowacyjnych procesach biznesowych. Dlatego też na wdrożeniach coraz częściej  staje się widoczne stosowanie sprawdzonych metod warsztatu architekta, jakie proponuje przykładowo zbiór standardów TOGAF https://www.opengroup.org/togaf/. W takich okolicznościach architektura rozwiązania dawno przestała być już tylko rysunkiem systemu na kartce papieru lub na slajdzie. Jest ona teraz dynamicznie zmieniającym się zasobem przedsiębiorstwa, obejmującym swym zakresem specyficznie przygotowane procesy biznesowe, gromadzone dane i  wszystkie niezbędne do ich przetwarzania, właściwe danej organizacji, środki techniczne.
 
Czy można zatem dalej brnąć w metody typu COMMAND AND CONTROL (jak je określa Maciek)? W wielu przypadkach od dawna stosowane są tzw. procedury wdrożeniowe, czy twarde przepisy mówiące o tym co i jak należy robić, by wdrożyć jakiś konkretny system. Często takie sposoby działania porównuje się do wodospadu: pokonywanie kolejnych progów jest ścieżką w ustalonym tempie, w jednym kierunku. Jednak w obecnym świecie nasyconym technologią może okazać się, ze na końcu tej ścieżki może czekać nas …rozczarowanie. Porównując to do ruchu ulicznego, nie da się zamknąć oczu i bezpiecznie pokonać zatłoczonego skrzyżowania. Trzeba mieć oczy szeroko otwarte i patrzeć w lusterka. Odpowiednikiem tego podejścia są metody zwinne (ang. agile). Powstały one dla potrzeb tworzenia oprogramowania, ale coraz częściej zaczynają być stosowane w przedsięwzięciach wdrożeniowych wstępnie przygotowanych pakietów. Paradoksalnie, metody zwinne mogą znacznie uprościć wdrożenie rozwiązań poprzez szersze zastosowanie pakietów prekonfigurowanych i rozwiązań w chmurze (typu SaaS).
Na końcu warto wspomnieć o sile prototypowania – czyli o Design Thinking. To podejście umożliwia jeszcze szerszą zmianę sposobu myślenia wdrożeniowców. Zamiast twardo się trzymać swoich schematów i procedur, może lepiej jest na początku zrozumieć dogłębnie odbiorcę własnej pracy? Może warto wejść w jego buty, poczuć, jak to jest, gdy się jest nim, zbudować prototyp dla niego, porozmawiać o odczuciach i  emocjach? Prototyp nie musi być działającym produktem. Wystarczy, że jest to makieta, która te odczucia i emocje wyzwoli.          Podsumowując można stwierdzić, że czasie mojej pracy w korporacji zaszły znaczące i zauważalne zmiany:

  • Z jednego produktu powstała konstelacja rozwiązań branżowych, dziedzinowych i technologicznych
  • Z jednego zawodu konsultanta – powstały role i funkcje o charakterze generalistycznym i specjalistycznym
  • Dyskusja o modułach oprogramowania przeistoczyła się w dyskusję o komponentach architektury rozwiązań
  • Proceduralne, liniowe podejście do zastosowania (wdrożenia) technologii zmieniło się w podejście zwinne o dużym nasyceniu interakcji pomiędzy zespołami i poszczególnymi uczestnikami przedsięwzięcia.
  • Tworzenie rozwiązania opartego o projekt zdeterminowany myśleniem technicznym (np. układ pól w bazie danych, techniczna struktura obiektów informacyjnych w systemie) jest coraz częściej poprzedzone myśleniem empatycznym (badanie i doświadczenie emocji użytkowników na etapie prototypu).

 
Taka transformacja, jak napisał Maciek, jest możliwa i chcę ją poddać pod rozwagę tym, którzy myślą z troską o zastosowaniu nowoczesnych technologii informatycznych w gospodarce – na przykład w kontekście rozwoju koncepcji Przemysłu 4.0.

W blogu Spostrzeżenia 2018/02/13 - 11:04 Czytaj

Business Dialog Bulletin - widok książki

Premium Drupal Themes by Adaptivethemes