-
Data: 2003-12-29 13:30:09
Temat: Re: szykuja sie obwarowania zawodu informatyka?
Od: "JL" <jl@[cut]noemail.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]
Użytkownik "Jarosław Wiechecki" <j...@p...onet.pl> napisał w wiadomości
news:bsp0hr$pj3$1@news.onet.pl...
> Tak, tylko zauważ, że system jest tak dobry jak obsługujący/zarządzający
nim
> ludzie. Jeśli oni nie mają wiedzy, umiejętności lub są zwykłymi tłumokami
to
> nawet najlepszy system nie pomoże.
Powoli dochodzimy do podobnych wniosków :)
> > Wezwania do zapłaty są często decyzją strategiczną i scedowanie tego na
> > system
> > zazwyczaj kończy się nieprzyjemnie.
>
> Wezwania tak. Analiza płatności dokonana ręcznie jest zawsze mniej
efektywna
> niż analiza dokonana automatycznie.
Nawet przy systemach billingowych ostatnie słowo powinien mieć człowiek.
Podam Ci parametry do przykładu, a scenariusz wymyśl sobie dowolny.
Klient jednego z operatorów posiada ok 1000 telefonów komórkowych. Klient
jest
prestiżowym partnerem, obsługiwanym przez 2 keyaccountów. Z jakiegoś powodu
operator odnotowuje opóźnienie w płatnościach, system automatycznie wyzwala
procedurę
windykacji (mail ze stosowną treścią wędruje do firmy windykacyjnej).
Teraz postać klienta - firma ciesząca się dużym prestiżem w branży, notowana
na giełdzie, obcertyfikowana wzdłuż i wszerz.
Pojawienie się wezwania do zapłaty uruchamia stosowną procedurę obsługi.
Do badania zasadności roszczenia zostaje włączony dyrektor finansowy,
prawnik,
główna księgowa itp. Okazuje się, że... zawinił bank/system FK u operatora
/system u klienta, w każdym razie opóźnienie było nieznaczne. Nie mogło być
inne,
wszak zadziałał automat kontrolujące terminy spływu należności.
Dla poprawy nastroju przyjmijmy, że rzecz dzieje się w momencie zakończenia
przez
klienta roku obrachunkowego...
Resztę wedle uznania dopisz sobie sam.
> Częściowo rozumiem Twój punkt widzenia.Niestety, obok całkiem przydatnych
> możliwości działy marketingu obiecują gruszki na wierzbie.
Ale zostawmy działy marketingu w spokoju, bo żaden dział marketingu nie ma
bezpośredniego wpływu na przebieg prezentacji systemu ani negocjacji
handlowych.
Poza tym jesteś w błędzie myśląc, że w dzisiejszych czasach klienci kupują
systemy klasy ERP po obejrzeniu ulotki.
Są klienci gotowi zapłacić za przeprowadzenie analizy przedwdrożeniowej
przez
niezależną firmę. Najdłuższe zapytanie ofertowe jakie miałem okazję oglądać,
dotyczące
funkcjonalności produktu, czy też lista wymagań krytycznych jak kto woli,
miało objętość ok.
60stron A4. Nie sądze, żeby był to rekord na rynku.
> > Problem ogólnie znany naszym producentom systemów.
>
> Tu masz rację. Tylko, że interfejs nie jest najważniejszą rzeczą w
systemie.
Jest elementem wiążącym efektywność obsługi z rozwiązaniem zaszytym w logice
systemu. Zatem w większości przypadków stanowi element krytyczny aplikacji.
> Jeśli zarząd podejmuje decyzję o wyborze systemu tylko i wyłącznie na
> podstawie materiałów dostarczonych przez producenta systemu, skończy się
tak
> jak opisujesz w dalszej części.
To zagadnienie jest na tyle złożone, że wydaje mi się iż nie wypracowano
dotąd
złotego środka na ominięcie problemu.
Referencje pisze marketing producenta dogaduje się z osobą odpowiedzialną
za administrację systemem, gość dostaje pakiet telewizji cyfrowej w rocznym
abonamencie
a dzwoniącemu ciekawskiemu opowiada głupoty. To sprawia, że wiarygodność
produktów jest trudno weryfikowalna.
> Niestety, w większości firm na świecie, nie
> wciąga się pracowników do zarządzania, nie wysłuchuje się ich opini
> dotyczących udoskonalenia stanowiska pracy czy też procesów.
Ma to swoje głębokie uzasadnienie. Z moich doświadczeń wynika, że ponad 90%
opinii pracowników na temat jakości ich stanowiska pracy, ew. jego
udoskonalenia
wygląda mniej więcej tak:
krytyka:
96% - próba uzasadnienia własnej nieporadności tzw. dupokrytka
2% - próba scedowania niechcianych, nielubianych czynności na dowolnie inną
lub wskazaną osobę/komórkę organizacyjną.
1% - rzeczywiste, sensowne wnioski dot. udoskonalenia procedur
1% - pretensje dot. jakości obsługi przez serwis wewnętrzny (administrator
systemu,
serwis producenta itp.)
Propozycje zmian i ulepszeń:
98% - lista lokalnych problemów do rozwiązania. Istotnych z punktu widzenia
spraw do załatwienia, kompletnie bez znaczenia dla kształtu
systemu.
1% - żądania systemowego rozwiązania problemu wynikającego ze specyfiki
lokalizacji jego wystąpienia (np. jakaś wybrana operacja w firmie
wielooddziałowej)
1% - propozycje istotne z punktu widzenia całej organizacji (firmy, holdingu
itp.)
> Niestety, błędne wdrożenie to nie wina systemu jako takiego, tylko
> komunikacji wewnątrz zespołów wdrożeniowych, nieumiejętności sformułowania
> potrzeb przez kupującego, opisania procesów wewnątrz firmy.
Problematyka ta jest dużo bardziej złożona, o czym wspominałem.
W kontekście naszej dyskusji nie ma sensu rozwijać tego wątku.
Nie czuję się odpowiednio kompetentny do szczegółowego komentowania
technicznych zagadnień związanych z wdrożeniami.
> Problemem było, niestety,
> kierownictwo, które wszelkie wprowadzone i opisane procesy traktowało jako
> niezmienne.
No tak, ale to dowód na to, o czym wspominałem wcześniej.
> > Z powodu wdrożenia bardzo znanego na rynku, choć niepopularnego w Polsce
> > (zaledwie kilka wdrożeń) handlowcy pewnej bardzo znanej na rynku IT
firmy
> > przez 3 miesiące nie byli w stanie podawać cen towarów przez telefon, na
> > czym ucierpiała zarówno firma jak i jej partnerzy handlowi.
>
> :) Nie wiem o jakiej firmie mówisz.
Przez sympatię do kolegów z tej firmy przemilczę temat :)
> Znam parę innych. Nadal jednak będę
> twierdził, że nie jest to wina systemu, lecz ludzi.
Jarku nie będę zdradzać przepisów szefa kuchni, ale uwierz, że niektóre
rzeczy da się oszacować.
Kilka parametrów:
1. Data wypuszczenia pierwszej wersji.
2. Daty wypuszczania kolejnych wersji upgrade i update + opis zmian
(widać czy są to rozwiązania funkcjonalne czy błędy.) Informacja ta
zazwyczaj
jest dostępna dla klienta np. jako komentarz do wersji)
3. Ilość betatesterów, narzędzia i metodologię testowania, okres testowania
danej wersji.
4.
5.
6.
7.
8.
9.
10.
Resztę pozwól, że zachowam dla siebie :)
Ww. informacje są dla klienta możliwe do uzyskania i nawet osoba niezwiązana
zawodowo
z projektami IT jest w stanie wyciągnąć prawidłowe wnioski.
> Bardzo często
> przypadkowych, niewykształconych. Zwłaszcza w dużych firmach, w których
> kierownictwo dobierane było na zasadzie: ten mi dobrze d..ę liże, zostanie
> moim zastępcą.
Nie spotkałem w swojej praktyce sytuacji, w której decyzja o zakupie systemu
tej klasy podejmowana była jednoosobowo.
Nie twierdzę, że takich precedensów nie ma.
> Ja całkowicie się z Tobą zgadzam. Dopóki o wdrożeniu systemu będą
decydowali
> ludzie, którzy tak naprawdę nie wiedzą jak funkcjonuje zarządzana nimi
> firma, jakie ustaliły się procesy, dopóty system nie będzie wdrożony
> poprawnie.
Jak najbardziej :)
> > (czytaj próbowali coś mi sprzedać) mieli tylko jeden pomysł na biznes w
> > Polsce.
> > Sprzedać moim klientom, po czym przejąć nad nimi "opiekę".
>
> Tak, Tak, Tak. :) A czy polscy producenci tak nie postępują?Niestety, tak.
;-) to się nazywa konsolidacją rynku.
Mam kilka pomysłów na to jak ten proces skutecznie przyspieszyć, może uda mi
się
go komuś sprzedać ;-)
> > Znam natomiast historię nieudanego wdrożenia CRM u 2 gigantów
> > oprogramowania.
>
> Tutaj należałoby ustalić, czy wszyscy potrzebują wszystkich systemów.
Na reszcie doszliśmy do sedna sprawy i wróciliśmy do początku dyskusji.
Moim zdaniem pytanie od początku zostało źle postawione.
Ja zadałbym je w sposób następujący:
"Czego potrzebują 'nazwani' klienci?"
W moim przekonaniu firmy IT, które potrafią w ten sposób zdefiniować
to podstawowe pytanie i razem z klientem znajdą na nie odpowiedź mają
szansę na przetrwanie. Reszta, podobnie jak kanał subdystrybucji IT, w ciągu
kilku
najbliższych lat znajdzie swoje miejsce na liście firm zasłużonych dla
rozwoju
rynku IT w Polsce.
Odpowiedzią na to pytanie wcale nie musi brzmieć "CRM", byc może wystarczy
fragment jego funkcjonalności, wspierający działania pre-sales, bądź jako
narzędzie
planowania targetów itp. Takie rozwiązanie możliwe będzie dzięki powstaniu
tzw. "platform biznesowych" - systemów przeznaczonych do rozbudowy i
integracji
zgodnie z wymaganiami klienta.
Przeglądając oferty producentów oprogramowania nie mogę się nadziwić kto dał
zgodę na inwestycję w wyprodukowanie pokraki szumnie zwanej CRMem,
zintegrowanej z kompletnie niczym. Nie dającej się nawet zintegrować z
innymi
systemami danego producenta bez interwencji programisty producenta.
Oczywiście istnieje jeszcze inny realny - aczkolwiek czarny dla sceny
developerów
scenariusz. Jedynie słuszny program do obsługi małych i średnich
przedsiębiorstw.
BTW. już puka do ich drzwi...
No ale dość gdybania ;-)
> Nie. Stany nigdy nie będą się w 100% zgadzać. Jednak prawdopodobieństwo,
że
> ilości widziane na ekranie terminala są na magazynie jest bliskie
jedności.
> W przypadku braku jakiegokolwiek systemy, musielibyśmy tracić czas na
ręczne
> sprawdzanie.
Co niestety ma miejsce w rzeczywistości.
> > Czy w bazach nie zmieniły ceny po korekcie, nie zmieniała cena zakupu
> > po przewalutowaniu? Nie kaszaniły się stany po ręcznych korektach?
>
> Po ręcznych korektach nie. Ceny również nie zmieniały się po korektach.
Były
> problemy po przewalutowaniu, to fakt.
Przykład był podchwytliwy. Nie słyszałem, żeby ktoś zadowalająco rozwiązał
ten problem.
Problemy z korektami zaczynają się przy uśrednianiu ceny zakupu.
Łatwo zrobić sobie taką symulację choćby w excelu.
Kolejnym problemem nierozwiązywalnym jest VAT.
Różnie liczony, daje różnicę przy zaokrągleniach.
Dopóki ustawodawca tego nie usankcjonuje, doputy problem będzie otwarty.
> > Niektóre panie, dzięki np. błędom replikacji baz tegorocznego sylwestra
> > spędzą nad wyprowadzaniem stanów.
>
> Cóż, w tym przypadku znowu zawinił człowiek.
Który projektował rozwiązanie. :)
> Nic nie wyręcza człowieka od myślenia czy pracy. Za wyjatkiem
przełożonego,
> który myślenie podwładnego uważa za atak na swoją pozycję.
BTW strasznie atakujesz tych domniemanych przełożonych ;-)
Może czas na awans? :-)
> Niestety, wprowadzenie
> certyfikowanych przez państwo lub inną instytucję informatyków, nie
> spowoduje, że unikniemy błędów.
Co do tego jesteśmy zgodni :)
Pozdrawiam
JL
Następne wpisy z tego wątku
- 29.12.03 22:47 Nina M. Miller
- 30.12.03 08:01 Wojciech Jakóbczyk
- 30.12.03 08:45 Nina M. Miller
- 30.12.03 09:28 Rafał
- 30.12.03 09:31 Rafał
- 31.12.03 10:18 w...@p...onet.pl
- 02.01.04 11:54 Marek
Najnowsze wątki z tej grupy
- Pedalskie ogłoszenia na rządowej s. WWW oferty.praca.gov.pl:443
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Ile powinien trwać tydzień pracy?
- Jakie znacie działające serwery grup dyskusyjnych?
- is it live this group at news.icm.edu.pl
- praca 12/24
- 5 minut przerwy przy komputerze
- raczej już nigdy nie będę pracował w Polsce
- Stanowiska sztucznie tworzone
- Re: SOLUTIONS MANUAL: Optical Properties of Solids 2nd Ed by Mark Fox
- zapłata
- Re: Cwana cwaniurka czyli niemieccy oszuści.
- Re: Cwana cwaniurka czyli niemieccy oszuści.
- Jawność zarobków wszystkich
- rozmówki przy wódeczce...
Najnowsze wątki
- 2024-12-28 Warszawa => Full Stack .Net Engineer <=
- 2024-12-28 Warszawa => Sales Assistant <=
- 2024-12-28 Warszawa => Programista Full Stack .Net <=
- 2024-12-28 Warszawa => Full Stack web developer (obszar .Net Core, Angular6+) <=
- 2024-12-28 Katowice => Head of Virtualization Platform Management and Operating S
- 2024-12-28 Błonie => Analityk Systemów Informatycznych (TMS SPEED) <=
- 2024-12-28 Warszawa => Senior Frontend Developer (React + React Native) <=
- 2024-12-28 Żerniki => Employer Branding Specialist <=
- 2024-12-27 Rzeszów => System Architect (background deweloperski w Java) <=
- 2024-12-27 Kraków => Application Security Engineer <=
- 2024-12-27 Gorzów Wielkopolski => Konsultant wdrożeniowy Comarch XL/Optima (Ksi
- 2024-12-27 Wrocław => Solution Architect (Java background) <=
- 2024-12-27 Poznań => Key Account Manager (ERP) <=
- 2024-12-27 Gdańsk => Full Stack .Net Engineer <=
- 2024-12-27 Katowice => Programista Full Stack .Net <=