Wyniki Megapanel PBI/Gemius za maj 2011

Polskie Badania Internetu Sp. z o.o. (PBI) i firma badawcza Gemius SA, współpracujące w zakresie realizacji badania ?Megapanel PBI/Gemius? ? standardu pomiaru oglądalności witryn i aplikacji internetowych w Polsce, opublikowały wyniki za maj 2011.

Pierwsze trzy pozycje oglądalności stron to  kolejno od najlepszej: grupa Google, grupa Onet, grupa Wirtualna Polska – Orange. W tym grupa NK.pl na pozycji 7., Facebook na pozycji 9., grupa Wikipedia na pozycji 11.,  Microsoft na pozycji 14. więc jak widać nasza rodzima NK dobrze się trzyma, szkoda, że nie ma charakterystyki odwiedzających… Prawdę mówiąc zaskakuje mnie pozycja Microsoftu, czy jest to wyniki klikana w Pomoc w środowisku Windows czy też realne zainteresowanie produktami.

W rankingu domen króluje kolejno google.pl, onet.pl, youtube.com. W tej “konkurencji” w pierwszej dwudziestce pojawiły się blogspot.com (poz. 17.) oraz blox.pl (poz. 20.) co pokazuje, że treść tworzona przez użytkowników sieci także ma czytelników.

Jeżeli jednak spojrzeć na poszczególne witryny a nie grupy to liderem jest allegro.pl z duża przewagą do nastęnych: onet.pl który dla odmiany ma więcej użytkowników tak więc allegro to mniej ale bardzo aktywnych użytkowników.

Na koniec ranking aplikacji: liderem jest Gadu-Gadu, drugi jest Skype. Co ciekawe blisko tej czołówki mamy MediaPleyer’a w Windows.

(pobierz Wyniki_Megapanel_PBI_Gemius_maj_2011).

W poprzednim artykule napisałem:

Ogólnie opinia, zalecane podejście przez Fowlera to: jeżeli proces wymagający wsparcia nowym oprogramowaniem, to proces kluczowy dla utrzymania konkurencyjności lepiej stworzyć oprogramowanie dedykowane do tego procesu. Jeżeli to jeden z procesów  pomocniczych, efektywniej będzie kupić gotowe oprogramowanie i dostosowanie do niego procesu w firmie. Co ciekawe, podobnie jak ja, zaleca w przypadku gotowego oprogramowania dostosowanie się do niego a nie dostosowywanie oprogramowania do siebie. (czytaj Dostosowanie oprogramowania: kiedy?).

Dużo się mówi, i słusznie, o tym że analizę wymagań powinna poprzedzić rzetelna analiza biznesową. Nie jest to jednak to, co robią w większości “analitycy biznesowi” dostawców oprogramowania ERP. Ci przygotowują swoje firmy i swoich klientów, do wdrożenia sprzedanego im już oprogramowania.

Tym razem “pociągnę” temat “co dopasowywać i do czego”.

Jak już wspomniano potrzebna jest nam wiedza o tym, które procesy są w naszej firmie procesami kluczowymi, a które pomocniczymi. Nie ma na to jednoznacznej odpowiedzi. Jest teza, postawiona przez Michaela E. Portera, mówiąca, że firma powinna mieć jedną specjalizację, jeden kluczowy czynnik budowy przewagi rynkowej nad konkurencją. Nie można skutecznie konkurować “we wszystkim i ze wszystkimi”. Pewnej wskazówki dostarcza M.E.Porter w swoim (obecnie wręcz epokowym) dziele: “Competitive Advantage” wydanym w 1985 roku (polskie wydanie: [[Strategie Konkurencji, Michael E. Porter, MT Biznes, Warszawa 2006]]).

Jednym z najsłynniejszych diagramów z tej książki jest ten:

Celowo przytaczam wersją oryginalną, gdyż w bardzo wielu książkach i stronach WWW, model ten jest “kaleczony”: po pierwsze błędnie nazywany “metodą”, po drugie “inbound logistics” jest błędnie tłumaczone na “logistyka wewnętrzna” zamiast “logistyka zaopatrzenia (produkcji, przyp. mój)”.  Kolejnym, pomijanym często elementem tego diagramu, jest “margin” czyli marża (tu jako monetarnie wyrażona wartość dodana) jaką tworzą te procesy, a wartość tę tworzą wszystkie procesy, nie tylko te główne. Wystarczy jednak przeczytać treść książki, by nie mieć tych wątpliwości: procesy operacyjne tworzą produkt, rynkową wartość dodaną (i marżę), procesu wspierające tworzą marże swoją efektywnością (możliwie niskie koszty).

Jak to się ma do wymagań?

Przytoczmy jeszcze raz, dla przypomnienia, wspomniany na początku cytat:

…jeżeli proces wymagający wsparcia nowym oprogramowaniem, to proces kluczowy dla utrzymania konkurencyjności lepiej stworzyć oprogramowanie dedykowane do tego procesu. Jeżeli to jeden z procesów pomocniczych, efektywniej będzie kupić gotowe oprogramowanie i dostosowanie do niego procesu w firmie…

Zwracam uwagę, że “dedykowane” to także “złożone z indywidualnie dobranych gotowych komponentów”.

Powyższy model, już po przetłumaczeniu i drobnej korekcie:

Procesy (konkretne aktywności) Porter dzieli na dwa ich obszary:

1. wspierające
2. kluczowe (główne)

Podział ten ma swoje źródło w tym, gdzie powstaje (potencjalnie może powstać) największa wartość dodana (źródło zysku). Porter uważa, że obszary, w których firmy powinny budować swoją przewagę to te, które dotyczą bezpośrednio oferowanych usług i produktów. Pozostałe jednak nie mogą być pomijane gdyż, jak widać na diagramie, marże budują wszystkie procesy. Firma jednak może być np. mistrzem logistyki w swojej branży (ma najlepszy system zaopatrzenia w surowce, albo najsprawniej dostarcza produkty do klientów) czy mistrzem skuteczności docierania z ofertą do klientów (marketing i sprzedaż) ale trudno budować przewagę np. Kopalni, i być mistrzem własnej księgowości wewnętrznej czy zaopatrzenia w segregatory własnych pracowników (Zaopatrzenie).

Tak więc (w pewnym uproszczeniu) można “w ciemno” wybrać na rynku gotowy produkt i wdrożyć go, nawet poświęcając pewne własne zwyczaje w obszarze zarządzania personelem, wewnętrzną administracją, rachunkowością, rozwojem technologii. Tu warto zwrócić uwagę na to, że używane maszyny – poza posiadanymi patentami – może mieć każdy nasz konkurent, dlatego budowa trwałej przewagi na środkach produkcji jest raczej wątpliwa strategią.

Tak więc analizując firmę i określając wymagania na system ERP warto rozważyć podejście, w którym obszarze procesów wspomagających wdrożone zostanie gotowe oprogramowanie bez żadnych kastomizacji (czyli szybko i relatywnie tanio), a w którym warto zaprojektować coś specjalnie dla siebie. Analiza biznesowa i wewnętrzny model wartości wskaże nam obszar, który należy zinformatyzować dokładnie tak jak obecnie pracuje, bez żadnych kompromisów, bez naginania się do dostarczonego ERP. Jak to zrobić? Stworzyć poprawny model całej firmy, wskazać na nim kluczowe źródło zysku i przewagi rynkowej, i dla tego obszaru działalności stworzyć dedykowane rozwiązanie (przeczytaj artykuł o analizie gap/fit). Podejście takie jest stosowane.

Badania pokazują, że liderzy rynku, bez względu na branżę, to firmy dobrze zarządzane a nie te, które najwięcej wydały na IT.

Podejście to wymaga dużej odwagi i samodzielności, ignorowania tak zwanych modeli referencyjnych (bo te są dobrymi praktykami a nie czymś co należy skopiować), owocuje jednak sukcesami. Niestety często zdarza się, że wdrożenie systemu ERP niszczy przewagę firmy, gdyż nowa technologia zamiast ją umocnić niszczy kompromisami i kopiowaniem modeli innych firm (nie raz konkurentów) wszystko to co odróżniało ją od innych.

Za zakończenie polecam gorąco drugą książkę Portera: Porter o konkurencji, Michael E. Porter, PWE, Warszawa 2001. W tej znajdziemy zbiór dziewięciu artykułów na temat budowania konkurencji i jej utrzymaniu. W szczególności warto poznać artykuł “W jaki sposób informacja wpływa na przewagę konkurencyjną”. Pięć zasad, które mogą pomóc w budowaniu przewagi na bazie informacji, odsyłam do książki , warto. To przyczynek to napisania kilku słów o systemach wspomagania decyzji ale to inny temat, nie ERP…

Na zakończenie

Wybór i wdrożenie systemu wspomagającego zarządzanie powinno być poprzedzone wnikliwą analizą, pozwalającą zrozumieć znaczenie i wpływ na wyniki firmy, każdego jej obszaru działania. Wybór systemu ERP powinien być świadomy: celu każdego jego elementu i skutków jego zastosowania. Wdrażanie przypadkowo (na bazie ogólnych oczekiwań) wybranego systemu ERP daje także przypadkowe efekty, zaś późniejsze kosztowne dostosowywanie go do własnych potrzeb, z reguły niszczy potencjalne finansowe korzyści z jego wdrożenia. 

Tak więc analiza przedwdrożeniowa to jest jakaś praca, jej produktem mogą być różne treści. Dlatego właśnie warto pytać wykonawcę takiej analizy o to, co będzie jej produktem i do czego to coś posłuży. (Wymagania na oprogramowanie ERP a analiza przedwdrożeniowa ? gdzie różnica?).

Artykuł (po pewnym przeredagowaniu i uzupełnieniu) ukazał się wydawnictwie COMPUERWORLD Aplikacje biznesowe Kompendium Czerwiec 2011. Fragment artykułu:

Poprawny model firmy na potrzeby analizy wymagań to: mapa procesów oraz już poza nią ale powiązane referencjami z tą mapą, dokumenty takie jak procedury dla wybranych czynności, specyfikacje stanowisk i kompetencji, wzory dokumentów, reguły biznesowe. Mapa procesów to obraz przepływu pracy w firmie. Każdy podmiot będący organizacją ludzi, którzy wykonują jakąkolwiek celową pracę, da się opisać w postaci procesów czyli łańcuchów czynności wymagających czegoś na swoim wejściu i dających w efekcie coś na wyjściu. To ostatnie to nic innego jak cel danej pracy. Jednak modelowanie procesów nie ma nic wspólnego z prostym obrazkowym zapisywaniem czynności poszczególnych pracowników. Model procesowy firmy to jej wewnętrzny łańcuch wartości. Szczegóły działań to metoda ich osiągania w konkretnej firmie. Jeżeli model zawiera te szczegóły, to staje się kompletnie nieprzydatny, bo ukrywa sedno sprawy. Dobry model rozgranicza: łańcuch czynności, reguły biznesowe oraz ograniczenia. Kolejne czynności są kandydatami na potrzebne funkcjonalności nowego systemu. Jednocześnie system powinien pozwalać na zarządzanie regułami biznesowymi i definiowanie procedur. Częścią modelu powinien być również uporządkowany model informacji. Ta swego rodzaju taksonomia powinna opisywać powiązania między obiektami biznesowymi ? np. faktura VAT powstaje na bazie zamówienia od klienta lub zamówienia wewnętrznego, jest powiązana obligatoryjnie tylko z jednym pracownikiem, który ją wystawił itd. Dopiero na etapie analizy wymagań decydujemy, czy czynność fakturowania będzie włączona w zakres projektu wdrożenia. Jeśli tak to, analizujemy czy użytkownik sam wpisze potrzebne dane, czy ? i w jaki sposób – zostaną one wyliczone.

Użycie modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne – wystarczy go opisać dodatkowo zakresem projektu i rozesłać do dostawców i zapytać czy ich system pasuje do modelu oraz ile ten produkt kosztuje rok po roku. Jednocześnie dobrze wykonany model organizacji nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt jego wykonania, a często stanowią zbędne ograniczenia. Dobry model powstaje z użyciem standardów i dobrych praktyk. Do typowych standardów należą: notacja BPMN (Business Process Modeling Notation), UML (Uniefied Modeling Langualge), AchiMate/TOGAF, Siatka Zachmanna, Business Motivation Model. Do dobrych praktyk np. wzorce projektowe czy zalecenia Business Rules Group.

Kompletny artykuł: CW Czerwiec 2011 skan artykułu JZelinski

Zachęcam do zakupu całego wydania COMPUTERWORLD Aplikacje Kompendium ERP Czerwiec 2011.

Problem dostosowywania (tak zwanej kastomizacji) gotowego oprogramowania nie od dziś jest dyskutowany. Jak wspomniałem w artykule o psuciu systemów ERP, firmy wdrażające najczęściej preferują dostosowywanie (tak zwana [[kastomizacja]]),  producenci tego oprogramowania dla odmiany, odradzają tę ścieżkę. Popatrzmy co na to Martin Fowler, znany w branży IT doświadczony projektant i developer, człowiek znany z tego że napisał naprawdę dużo biznesowego kodu:

A common question in IT departments is whether to provide a capability by building custom software or by buying a package. For longer than I’ve been programming the debate has raged about how to make that choice. My base position on this is founded on the UtilityVsStrategicDichotomy. Boiled down this means that if the business process you are supporting is part of your competitive advantage you should build custom software, if not you should buy a package and adjust your business process to fit the way the package works. (źr. PackageCustomization).

Fowler pyta o to, o co wielu wielu informatyków: czy dostarczenie firmie kolejnych nowych możliwości, powinno się realizować poprzez napisanie (tworząc dedykowane) potrzebne nowe oprogramowanie, czy poprzez zakup gotowego oprogramowania. Ogólnie opinia, zalecane podejście przez Fowlera to: jeżeli proces wymagający wsparcia nowym oprogramowaniem, to proces kluczowy dla utrzymania konkurencyjności lepiej stworzyć oprogramowanie dedykowane do tego procesu. Jeżeli to jeden z procesów  pomocniczych, efektywniej będzie kupić gotowe oprogramowanie i dostosowanie do niego procesu w firmie. Co ciekawe, podobnie jak ja, zaleca w przypadku gotowego oprogramowania dostosowanie się do niego a nie dostosowywanie oprogramowania do siebie.

Z mojej strony dodam, że to kolejna opinia bardzo doświadczonej osoby, z której wynika, że system ERP raczej należy traktować jako federację zintegrowanych programów dziedzinowych, a nie jako jeden zintegrowany pakiet oprogramowania. Ten ostatni zawsze w jakimś obszarze będzie kula u nogi.

Wstęp

Ostatni artykuł szybko zaowocował pytaniem:

A jeżeli klient nie ma kompetencji do opisania projektu i musi kogoś z takimi kompetencjami wynająć, to jak ustalić cenę za tę usługę? (pytanie do artykułu Budżet na projekt IT).

Jeżeli klient nie ma kompetencji do opisania projektu (z reguły tak jest, bo firmy utrzymują kompetencje niezbędne do bieżącego funkcjonowania) to powinien po pierwsze ocenić co chce osiągnąć. Klient powinien co najmniej opisać po co to robi, np. “chcę zwiększyć sprzedaż do końca roku o 10%, albo “chcę usprawnić produkcję i obniżyć jej koszty o 15% w ciągu dwóch lat, itp. Z tych procentów, znając wartość sprzedaży czy koszty produkcji, łatwo oszacować progowy budżet rentowności tego projektu. Bywa, że to trudne, wtedy czasami łatwiej ocenić “ile stracę np. w ciągu roku jeśli nie wprowadzę tej zmiany”. Jednak konkretna wartość powinna być określona.

Wycena

Wycena kosztów analizy może być ustaleniem stałej kwoty, będącej ocenioną pracochłonnością i rozliczeniowym kosztem dnia analityka (tu jednak ktoś musi tę pracochłonność określić). Można opisać produkt, to jest oczekiwaną treść dokumentu wymagań, kto ma to jednak zrobić skoro klient tego właśnie nie wie. Tu można posłużyć się standardami, np. uznać, że produktem analizy wymagań jest dokument o zawartości opisanej przez IIBA (tu powinny powstać: modele procesów całej firmy, model dziedziny systemu, opis zakresu projektu, specyfikacja przypadków użycia i ich ograniczeń, specyfikacja reguł biznesowych) jednak do ustalenia jest cel analizy a z tego wynika jej stopień szczegółowości. Potem szukamy wykonawcy takiego opracowania.

Inna, często stosowana, metoda to analiza ryzyka i wynagrodzenie typu success-fee (premia za korzyści). Klient, na ile potrafi i jak, opisuje swoje potrzeby i wysyła takie wstępne zapytanie w rynek. Zbiera oferty i oblicza np. medianę (mediana jest bezpieczniejsza od średniej arytmetycznej) ich wartości. Tu pojawia się ryzyko, że “nieprofesjonalnie” opisane wymagań rękami klienta wymuszą (i słusznie) na oferentach narzuty na ryzyka tak opisanych wymagań. Ustala z analitykiem, że potrzebny mu dokument, którego nie potrafi sam opracować, koszt jego opracowania ustala się z góry np. na 10% wartości ww. mediany oferowanych kosztów dostarczenia oprogramowania.

Kolejny etap to wykonanie tego opracowania (analizy wymagań wg. metody ustalonej przez analityka) oraz wysłanie kolejny raz zapytania w rynek, tym razem w imieniu analityka 😉 (żeby się dostawcy nie zorientowali). Znowu zbieramy oferty i liczymy medianę. Następnie obliczamy różnicę pomiędzy ofertami i jeżeli są dla klienta korzystniejsze, to np. 20% tej różnicy wypłacamy analitykowi jako wynagrodzenie za korzyści. Jeżeli nie są korzystniejsze uznajemy, że dobrze wykonano pracę ale “nie przyczyniła się znacząco do poprawy sytuacji”.

Procenty są ustalone na bazie wiedzy z badań, mówiącej, że źle wykonana analiza przeciętnie podnosi koszty dwukrotnie a bywa, że znacznie więcej.

W pierwszej metodzie ryzyko w całości bierze na siebie klient, w drugiej jest rozłożone mniej więcej równo na obie strony: klienta i analityka. Ja w praktyce stosuję obie te metody a czasem metodę pośrednią (z góry ustalam wartość analizy ale na bazie znanych z badań ryzyk). Moim zdaniem wycena polegająca w 100% na metodzie “czas i materiał” jest ryzykowna gdyż zachodzi poważne ryzyko wykorzystania niewiedzy klienta do zawyżania jej wartości. Dobrą metodą jest zawarcie w umowie z analitykiem zapisu, że w trybie tak zwanego nadzoru autorskiego analityk uczestniczy w projekcie do końca, co powinno go zmotywować do jak najlepszej pracy a także klient zyskuje mediatora.

Najgorsze moim zdaniem rozwiązanie to podjęcie decyzji o wyborze produktu bez analizy, tylko na podstawie prezentacji systemu i zlecenie jego opracowania dokumentu wymagań, by na jego podstawie wdrażać (tworzyć) oprogramowania. Ta sytuacja to praktycznie całkowita utrata kontroli nad projektem przez klienta, oraz bardzo duże ryzyko, że zostanie to wykorzystane przez dostawce do budowania jego marży lub zawyżania pracochłonności. To klasyczna patologia, w której ktoś sam sobie stawia zadania, realizuje je i ocenia czy je wykonał, gdyż klient, jak już na samym początku stwierdzono, nie ma do tego kompetencji.

Praktyka pokazuje, że koszt analizy i projektowania w dobrze zarządzanym projekcie stanowi ok. 20% wartości całego projektu dostarczenia, dopasowania lub wykonania oprogramowania. Do tego może być wymagana dodatkowa analiza organizacji w celu oceny możliwości jej usprawnienia (optymalizacji procesów) i ustalenia wspomnianego progu rentowności. Projekty takie są tańsze od prowadzonych “typowymi metodami” o 30-50%. Te typowe metody to ankietowe (warsztatowe) pozyskiwanie wymagań i ich nieformalny zapis w postaci tabel, strukturalnego tekstu itp. zależnie od wykonawcy, te proste metody dają mniej lub bardziej opasłe, i niestety mało przydatne dokumenty.

Opisywane tu nie raz metody bazujące na modelowaniu przyszłego systemu (jego logiki biznesowej) i testowaniu czy model pozwala na spełnienie celu biznesowego dają oszczędności nawet 50%, a bywa, że znacznie większe, jeśli okaże się, że uniknięto zakupu jakiegoś zbędnego oprogramowania lub modułu. Koszt dobrze opracowanej analizy z dużym zapasem pokrywają oszczędności wynikające z braku wielu prototypów.

Podsumowanie

Analityka zawsze warto zatrudnić, poprzedzając to kontrolą tego co wytworzy. Dobry analityk zawsze wyceni projekt jako umowę o dzieło o konkretnym terminie i koszcie. Projekty w rodzaju czas i materiał to projekty w rodzaju “na początku nikt nic nie wie”. Warto je robić tylko w przypadkach, gdy tej wiedzy faktycznie nie ma, spodziewamy się systemu o wartości setek tysięcy złotych lub kosztowniejszych i zainwestowanie nawet kilkudziesięciu tysięcy w analizę, która pozwoli oszacować ryzyko wydania tych kilkuset, może mieć sens. W takich przypadkach i tak ustalamy (należy to zrobić) próg kosztów i ryczałtowe wynagrodzenie dla analityka, przy których uznamy, że dalsze prace już niczego nowego nie wniosą.