🚀 go-pugleaf

Franek B napisał(a):
> Na stronie:
> http://www.cdn.com.pl/xl/standard/wdrozenie.htm
>
> znajduje się taki oto żarcik:
> "1. Analiza przedwdrożeniowa 1-3 dni"
[ciach]

może dlatego wdrożenia w tej firmie wyglądają tak jak wyglądają:)

Użytkownik "Franek B" <balabanf@wpREMOVE-ME.pl> napisał w wiadomości 
news:egctol$btb$1@nemesis.news.tpi.pl...
> Pytanie do analityków i projektantów:
> Czy udało się wam kiedykolwiek zrealizować wymieniony zakres prac
> w terminie krótszym niż rok ?
>

Hm... :)
Ogólnie: jeżeli założymy prace metoda top-down czyli od ogółu do szczegółu 
to po 3 dniach mamy analizie o dokładności proporcjonalnej do czasu jej 
trwania :).

Zaś z drugiej strony, to nie musi trwać od razu rok. Ważne jest postawienie 
celu takiej analizie i zdefiniowanie końcowego produktu i jego roli w 
projekcie. Po pierwsze inaczej to wygląda przed wdrożeniem produktu gotowego 
(parametryzowanego co by to nie miało oznaczać) a inaczej przy pisaniu 
dużego systemu  od zera.

Po drugie Jeżeli analiza ma trwać rok a implementacja trzy to moim zdaniem 
po grzyba ten projekt skoro realia biznesowe zmieniają się nieraz nawet 
kwartalnie. Osobiście jestem zwolennikiem innego traktowania analizy wymagań 
prowadzonych dla produktów gotowych a innego dla pisanych od zera.

Nie jestem także zwolennikiem wieloletnich badań nad strukturą 
przedsiębiorstwa kończących się  setkami stron które kosztują zawrotne 
pieniądze i do niczego nie służą zamawiającemu bo ich po prostu nie rozumie.

.

-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

> Użytkownik "Franek B" <balabanf@wpREMOVE-ME.pl> napisał w wiadomości 
> news:egctol$btb$1@nemesis.news.tpi.pl.
..
>> Pytanie do analityków i projektantów:
>> Czy udało się wam kiedykolwiek zrealizować wymieniony zakres prac
>> w terminie krótszym niż rok ?
>>
>
> Hm... :)
> Ogólnie: jeżeli założymy prace metoda top-down czyli od ogółu do
> szczegółu to po 3 dniach mamy analizie o dokładności proporcjonalnej
> do czasu jej trwania :).

Innymi słowy: 'Komputery są, pracownicy są, obieg dokumentów jest...'.

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości 
news:87mz85ttjw.fsf@hector.domek...
> "Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:
>
>> Użytkownik "Franek B" <balabanf@wpREMOVE-ME.pl> napisał w wiadomości
>> news:egctol$btb$1@nemesis.news.tpi.pl.
> ..
>>> Pytanie do analityków i projektantów:
>>> Czy udało się wam kiedykolwiek zrealizować wymieniony zakres prac
>>> w terminie krótszym niż rok ?
>>>
>>
>> Hm... :)
>> Ogólnie: jeżeli założymy prace metoda top-down czyli od ogółu do
>> szczegółu to po 3 dniach mamy analizie o dokładności proporcjonalnej
>> do czasu jej trwania :).
>
> Innymi słowy: 'Komputery są, pracownicy są, obieg dokumentów jest...'.

To była analiza 10 sekundowa. ;)



-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

On Mon, 9 Oct 2006 07:29:25 +0000 (UTC), "Franek B"
<balabanf@wpREMOVE-ME.pl> wrote:

>Na stronie:
>http://www.cdn.com.pl/xl/standard/wdrozenie.htm
>
 
Ten link nie dziala.

A.L.

> Ten link nie dziala.

Rzeczywiście. Ten drugi też nie działa. Wczoraj działały.
To dobra wiadomość. Widocznie mój post na coś się przydał.

-- 
   Franciszek Bałaban

Franek B <balabanf@wpREMOVE-ME.pl> napisał(a): 

> > Ten link nie dziala.
> 
> Rzeczywiście. Ten drugi też nie działa. Wczoraj działały.
> To dobra wiadomość. Widocznie mój post na coś się przydał.
> 

No faktycznie :-)

Ale jak sie: "www.cdn.com.pl/xl/standard/wdrozenie.htm" wpisze w googla
i kliknie sie na 'Kopia' to stronka jest jeszcze do obejrzenia. :-)

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Franek B" <balabanf@wpREMOVE-ME.pl> writes:

> Rzeczywiście. Ten drugi też nie działa. Wczoraj działały.
> To dobra wiadomość. Widocznie mój post na coś się przydał.

Zmienił się tylko adres.

http://www.comarch.pl/cdn/Products/CDN+XL/CDN+XL+STANDARD/Wdrozenie.htm

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Tue, 10 Oct 2006 12:26:39 +0200, Marcin 'Qrczak' Kowalczyk
<qrczak@knm.org.pl> wrote:

>"Franek B" <balabanf@wpREMOVE-ME.pl> writes:
>
>> Rzeczywiście. Ten drugi też nie działa. Wczoraj działały.
>> To dobra wiadomość. Widocznie mój post na coś się przydał.
>
>Zmienił się tylko adres.
>
>http://www.comarch.pl/cdn/Products/CDN+XL/CDN+XL+STANDARD/Wdrozenie.htm

Ab-so-lut-nie fantastyczne! 

A.L.

> znajduje się taki oto żarcik:
> "1. Analiza przedwdrożeniowa 1-3 dni"
>
> Początkowo myślałem, że to pomyłka. Powinno być "lat" zamiast
> "dni". Podsumowanie całości okresu wdrożenia rozwiało jednak
> moje wątpliwości:
> "Razem 16 dni roboczych (3-4 tygodni)"
>
> Jest to znakomity :) wynik, choć jest tu jeszcze co nieco
> do zrobienia (rekord swiata osiągnięty w Polsce wynosi 0 dni
> przeznaczonych na analizę).
>
> Wynik jest godny podziwu, tym bardziej jeśli uświadomimy sobie
> zakres analizy, co jest wyjaśnione, tym razem rzeczowo na:
> http://www.cdn.com.pl/produkty/index_uslugi_analiza_potrzeb.htm
>
> "Przedmiotem analizy jest:
>  - Stan bieżący informatyzacji przedsiębiorstwa Klienta,
>  - Ustalenie struktury organizacyjnej przedsiębiorstwa,
>  - Opis procesów biznesowych,
>  - Główne problemy i miejsca krytyczne analizowanych procesów,
>  - Określenie obiegu dokumentów,
>  - Inwentaryzacja potrzeb informatycznych oraz zasobów,
>  - Zdefiniowanie mierników efektywności - stopnia osiągnięcia
>    celów,
>  - Propozycje zmian w strukturze organizacyjnej, systemie
>    zarządzania, zakresach obowiązków przedsiębiorstwa
>    - optymalizacja procesów biznesowych,
>  - Przygotowanie Zespołu Klienta do prac projektowych,
>  - Opracowanie projektu koncepcyjnego rozwiązania informatycznego,
>  - Analiza efektywności proponowanych wariantów,
>  - Analiza sprzętu komputerowego,
>  - Określenie ewentualnych zagrożeń projektu,
>  - Przygotowanie dokumentacji koncepcji oraz przedłożenie jej
>    do akceptacji."
>
> Pytanie do analityków i projektantów:
> Czy udało się wam kiedykolwiek zrealizować wymieniony zakres prac
> w terminie krótszym niż rok ?

Oni sprzedają już gotowe oprogramownanie CDN (do wszystkiego:).

To odbywa się na zasadzie mamy oprogramowanie (które pisaliśmy przez 
ostatnie kilka lat wdrażaliśmy w różnych firmach robiliśmy jego poprawki tak 
aby bylo lepsze i lepsze) i sprawdzamy czy waszej firmie uda nam się go 
wcisnąć i czy pomoże to waszej firmie. Z tym że jako oprogramowanie jest 
gotowe to to wy będziecie się musieli przystosować do naszego 
oprogramowania, a nie nasze oprogramowanie do waszej firmy.

No i w sumie w mniejszych przedsiębiorstwach takie oprogramowanie (do 
wszystkiego) nawet się przydaje bo pozwala wprowadzić jako taki porządek. 
Reasumując firmy są czasami tak głupio zarządzane że lepiej aby 
dostosowywały się do oprogramowania niż oprogramowanie do nich :). 
Podejrzeam że ta oferta jest skierowana właśnie do takich firm (czyli w 
sumie większości firm w Polsce).

Franek B <balabanf@wpREMOVE-ME.pl> napisał(a): 

> Na stronie:
> http://www.cdn.com.pl/xl/standard/wdrozenie.htm
> 
> znajduje się taki oto żarcik:
> "1. Analiza przedwdrożeniowa 1-3 dni"
[CIACH]
> Wynik jest godny podziwu, tym bardziej jeśli uświadomimy sobie
> zakres analizy, co jest wyjaśnione, tym razem rzeczowo na:
> http://www.cdn.com.pl/produkty/index_uslugi_analiza_potrzeb.htm

Sorry, Franek, ale ten drugi link co podajesz, to jest zupełnie inny
produkt/usługa, a nie wyjaśnienie co się mieści w zakresie tej analizy
przedwdrożeniowej 1-3 dni z pierwszego linku. Czyli to zaden zarcik

-MS

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Marcin pisze:
> Sorry, Franek, ale ten drugi link co podajesz, to jest zupełnie inny
> produkt/usługa, a nie wyjaśnienie co się mieści w zakresie tej analizy
> przedwdrożeniowej 1-3 dni z pierwszego linku. Czyli to zaden zarcik

Nie istnieje żadna poważna metodyka pozwalająca przeprowadzić
analizę wymagań dla przedsiębiorstwa przemysłowego w terminie
1-3 dni, również w przypadku wdrażania "gotowca". Dlatego pytałem
o możliwość wykonania analizy w terminie 1 roku, a nie w terminie
1-3 dniowym, czy nawet 1-3 miesięcznym. Złożoność problemów
w przedsiębiorstwie jest po prostu zbyt wielka, a powtarzalność
wyników analizy złudna. Dotyczy to także systemów "gotowców"
branżowo zorientowanych (!)

Nie wierzę w bajki o "powielarności systemów", "parametryzacji",
"szybkim i tanim wdrożeniu" it.p. Stwierdzam tak na podstawie
obserwacji życia, a nie że mi się tak wydaje. Wychodzi mi, że
przyczyną porażek wdrożen systemów jest z reguły brak rzetelnej
analizy. W dalszym ciągu jestem przekonany, że na stronce
zamieszczono żarcik.

Pozdrawiam
-- 
   Franciszek Bałaban

> Nie wierzę w bajki o "powielarności systemów", "parametryzacji",
> "szybkim i tanim wdrożeniu" it.p. Stwierdzam tak na podstawie
> obserwacji życia, a nie że mi się tak wydaje. Wychodzi mi, że
> przyczyną porażek wdrożen systemów jest z reguły brak rzetelnej
> analizy. W dalszym ciągu jestem przekonany, że na stronce
> zamieszczono żarcik.

A sprawdzałeś do czego jest to oprogramowanie CDN? 

Użytkownik "Franek B" <balabanf@wpREMOVE-ME.pl> napisał w wiadomości 
news:eh4hkg$5it$1@nemesis.news.tpi.pl...
> Nie wierzę w bajki o "powielarności systemów", "parametryzacji",
> "szybkim i tanim wdrożeniu" it.p. Stwierdzam tak na podstawie
> obserwacji życia, a nie że mi się tak wydaje. Wychodzi mi, że
> przyczyną porażek wdrożen systemów jest z reguły brak rzetelnej
> analizy. W dalszym ciągu jestem przekonany, że na stronce
> zamieszczono żarcik.

Z mojego życia:
- brak dobrej analizy to główny powód porażek wdrożeń
- brak modelu firmy i modelu systemu jako narzędzia do testowania hipotez to 
kolejna przyczyna porażek
- możliwe jest dobre wdrożenie parametryzowanego systemu pod warunkiem, że 
ma to sens w warunkach danej firmy (i tu pole do popisu dla analityków 
biznesowych), system taki jednak powinien pozwalać na modyfikowanie procesów 
jakie ma wbudowane  taki system

Każde wdrożenie powinno być poprzedzone:
- analiza biznesową
- wykonaniem modelu informatyzowanej firmy
- wykonaniem listy wymagań (ale w metodyce zorientowanej na produkty i 
odpowiedzialność a nie jakieś mapy procesików na bazie idiotycznych ankiet)
- symulacją czy planowany system ma szanse przynieść oczekiwane korzyści 
biznesowe (ile jest sens na niego wydać by był rentowny)

Z mojej praktyki wynika, że z pierwotnych szczegółowych map procesów na 
bazie ankiet po wdrożeniu zostaje niewiele więc po co to robić? Do 
zrozumienia firmy wystarczy jej model procesowy wykonany na bazie metodyki 
produkt: zobowiązanie-odpowiedzialność.

Pracochłonność każdego etapu zależy tylko od zakresu projektu, nie musi 
trwać w cale roku ale w trzy dni także nie wierzę, nawet gdyby to było 
wdrożenie samokopiującego bloczka do fakturowania.

Jedyne wytłumaczenie tak krótkiej analizy to wdrożenie z czapki gotowego 
systemu na zasadzie: Państwo od teraz pracujecie tak jak robi to ten 
program.


-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

> Jedyne wytłumaczenie tak krótkiej analizy to wdrożenie z czapki gotowego
> systemu na zasadzie: Państwo od teraz pracujecie tak jak robi to ten 
> program.

No i tak to pewnie wygląda :) po częci muszą pracować na tym co jest ale za 
to nie kosztuje ich to kilkuset tysięcy pln. A jak zaczynają sami pracować 
to sami mówią co im się nie podoba i co można by usprawnić wpadają na 
pomysły itd. Według mnie jest to lepszy pomysł niż pisanie pod daną firmę 
oprogramowania od zera. Lepiej dać na początku coś w co można poklikać i 
dopiero później to dostosować czy uwzględnić dodatkowe wymagania klienta niż 
za każdym razem zaczynać od nowa.

>> Jedyne wytłumaczenie tak krótkiej analizy to wdrożenie z czapki gotowego
>> systemu na zasadzie: Państwo od teraz pracujecie tak jak robi to ten
>> program.
>
> No i tak to pewnie wygląda :) po częci muszą pracować na tym co jest ale za
> to nie kosztuje ich to kilkuset tysięcy pln. A jak zaczynają sami pracować
> to sami mówią co im się nie podoba i co można by usprawnić wpadają na
> pomysły itd. Według mnie jest to lepszy pomysł niż pisanie pod daną firmę
> oprogramowania od zera. Lepiej dać na początku coś w co można poklikać i
> dopiero później to dostosować czy uwzględnić dodatkowe wymagania klienta niż
> za każdym razem zaczynać od nowa.

Jest to szalenie popularna w Polsce metodyka wdrożeń 3z
(zaoferować, zainkasować, zapomnieć), którą stanowczo odradzam.
Prezesi przedsiębiorstw często dają się na nią nabierać,
ignorując opinie informatyków, bo to rzekomo szybko, tanio.
Skutkami swojej błędnej decyzji później najchętniej obarczają
właśnie informatyków.

Firmy "komputerowe" wymigują się od modyfikacji gotowców.
Nie chcą mieć tyle wersji programu ile wdrożeń (krawcy też
wolą szyć garnitury niż dokonywać ich przeróbek). Jeżeli
jednak już po wdrożeniu pod naciskiem użytkownika zmieniają
coś w programie, to
najczęściej nowo przyjętym pracownikom, na ogół nie mającym
doświadczenia w programowaniu ani wystarczającej wiedzy
o modyfikowanym programie i strukturach danych z nim związanych.
O testowaniu po zmianach nie ma mowy. Czynność ta spada
całkowicie na barki użytkownika na zasadzie: "jak nie zadzwoni,
to znaczy ze jest OK".

Prawie zawsze pojawia się trudna do zatrzymania/złagodzenia
lawina błędów. Program coraz bardziej traci swoją strukturę.
Występują błędy integralności i związane z tym spustoszenia
danych, niespójności i różne absurdy w wydrukach, zawieszanie
się programów, fałszywe komunikaty o błędach it.p.

Moje spostrzeżenie:
Firmy "komputerowe" najbardziej brzydzą się analizą i testowaniem
(a są to przecież najważniejsze i najciekawsze etapy wdrożenia).
Dlaczego tak jest? Może ktoś potrafi wytłumaczyć bliżej ten
mechanizm.

BTW
A słyszeliście o clipperowych protezach - kołach ratunkowych
dla Oracle?

A słyszeliście o poszukiwanym na rynku pracy zawodzie:
"informatyk popychacz systemu zintegrowanego"? :)

Pozdrawiam
-- 
   Franciszek Bałaban

Franek B napisał(a):
>>>Jedyne wytłumaczenie tak krótkiej analizy to wdrożenie z czapki gotowego
>>>systemu na zasadzie: Państwo od teraz pracujecie tak jak robi to ten
>>>program.
>>
>>No i tak to pewnie wygląda :) po częci muszą pracować na tym co jest ale za
>>to nie kosztuje ich to kilkuset tysięcy pln. A jak zaczynają sami pracować
>>to sami mówią co im się nie podoba i co można by usprawnić wpadają na
>>pomysły itd. Według mnie jest to lepszy pomysł niż pisanie pod daną firmę
>>oprogramowania od zera. Lepiej dać na początku coś w co można poklikać i
>>dopiero później to dostosować czy uwzględnić dodatkowe wymagania klienta niż
>>za każdym razem zaczynać od nowa.
> 
> 
> Jest to szalenie popularna w Polsce metodyka wdrożeń 3z
> (zaoferować, zainkasować, zapomnieć), którą stanowczo odradzam.

Nawet jeśli przynosi firmie "wdrażającej" wymierne korzyści :-)?

> Prezesi przedsiębiorstw często dają się na nią nabierać,
> ignorując opinie informatyków, bo to rzekomo szybko, tanio.
> Skutkami swojej błędnej decyzji później najchętniej obarczają
> właśnie informatyków.
> 

To już niestety inna smutna bajka :-(.

> Firmy "komputerowe" wymigują się od modyfikacji gotowców.
> Nie chcą mieć tyle wersji programu ile wdrożeń (krawcy też
> wolą szyć garnitury niż dokonywać ich przeróbek). Jeżeli

Ja zawsze wolę dokonać przeróbki - jeżeli tylko klient za to zapłaci i 
nie muszę zostawać po godzinach:-).

> jednak już po wdrożeniu pod naciskiem użytkownika zmieniają
> coś w programie, to
> najczęściej nowo przyjętym pracownikom, na ogół nie mającym
> doświadczenia w programowaniu ani wystarczającej wiedzy
> o modyfikowanym programie i strukturach danych z nim związanych.

Na to nigdy bym się nie odważył.

> O testowaniu po zmianach nie ma mowy. Czynność ta spada
> całkowicie na barki użytkownika na zasadzie: "jak nie zadzwoni,
> to znaczy ze jest OK".
> 

Czyż nie na tym polego XP - włączeniu użytkownika w proces wytwarzania. 
Tak jest najtaniej, jednak nie udało mi się jeszcze użytkowników 
przekonać do tej metody :-(. Macie jakieś sprawdzone metody?

[...]
> Moje spostrzeżenie:
> Firmy "komputerowe" najbardziej brzydzą się analizą i testowaniem
> (a są to przecież najważniejsze i najciekawsze etapy wdrożenia).
> Dlaczego tak jest? Może ktoś potrafi wytłumaczyć bliżej ten
> mechanizm.
> 

Cięcie kosztów. Nie można zrezygmować z kodowania (produkt musi powstać) 
i wdrożenia (klient musi coś dostać, żeby zapłacił). Pozostaje analiza, 
projekt i testowanie - rzeczywiście najciekawsze fragmenty.

Pozdrawiam


-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Franek B <balabanf@wpremove-me.pl> napisal:
> Moje spostrzeżenie:
> Firmy "komputerowe" najbardziej brzydzą się analizą i testowaniem
> (a są to przecież najważniejsze i najciekawsze etapy wdrożenia).
> Dlaczego tak jest? Może ktoś potrafi wytłumaczyć bliżej ten
> mechanizm.

Niekompetencja tychze prezesow, ktorzy slyszac o analizie, projekcie
itd. stwierdzaja, ze placa wylacznie za program, a nie za kilkadziesiat
kartek, ktore "wicie, rozumicie" nikomu potrzebne nie sa.
Jak z kolei koszty analizy i porzadnego projektu wsadzisz w produkt
koncowy, to przegrywasz z krzakiem, ktory dziala w stylu
"jak daja, to brac, jak bija, uciekac".

Co wiec pozostaje, jak nie zamierzasz zmieniac branzy?
Poslugiwac sie gotowcem, z gory zakladajac jakos "good enough",
albo wyjazd z Polski :)
-- 
Pozdrawiam,

Jacek

Witam
  poniżej moje trzy grosze

> Użytkownik "Franek B" <balabanf@wpREMOVE-ME.pl> napisał w wiadomości 
> news:eh4hkg$5it$1@nemesis.news.tpi.pl...
>> Nie wierzę w bajki o "powielarności systemów", "parametryzacji",
>> "szybkim i tanim wdrożeniu" it.p. Stwierdzam tak na podstawie
>> obserwacji życia, a nie że mi się tak wydaje. Wychodzi mi, że
>> przyczyną porażek wdrożen systemów jest z reguły brak rzetelnej
>> analizy. 
Ja bym jednak powiedział że przyczyną porażki wdrożenia jest złe 
wdrażanie. Sama analiza potrzeb nie zastąpi dobrego podjęcia decyzji jak 
program ma być skonstruowany/wykorzystywany. Po pierwsze  w kontekście 
koniecznej rozbudowy modyfikacji, po drugie każdy duży program dla 
przedsiębiorstwa ma wiele rozwiązań na ten sam problem. Dobranie 
odpowiedniego obiegu informacji z jednoczesnym uwzględnieniem zarówno 
specyfiki firmy jak i możliwości programu to jest klucz do sukcesu.



W dalszym ciągu jestem przekonany, że na stronce
>> zamieszczono żarcik.
> 
> Z mojego życia:
> - brak dobrej analizy to główny powód porażek wdrożeń
Dobra analiza nie jest zła, tyle że nie wiadomo kiedy była dobra. Są 
udane wdrożenia po złej analizie i nieudane po dobrej. Bynajmniej nie 
umniejszam znaczenia analizy, tylko tłumaczę przyczynę nieufności.

> - brak modelu firmy i modelu systemu jako narzędzia do testowania hipotez to 
> kolejna przyczyna porażek
a czy jest możliwe utworzenie takiego modelu bez papieru i komputera, bo 
moim zdaniem jest

> - możliwe jest dobre wdrożenie parametryzowanego systemu pod warunkiem, że 
> ma to sens w warunkach danej firmy (i tu pole do popisu dla analityków 
> biznesowych), system taki jednak powinien pozwalać na modyfikowanie procesów 
> jakie ma wbudowane  taki system
to chyba jest masło maślane, wg mnie tu napisałeś: możliwe jest 
wdrożenie programu który nadaje się do danej firmy


> 
> Każde wdrożenie powinno być poprzedzone:
> - analiza biznesową
> - wykonaniem modelu informatyzowanej firmy
> - wykonaniem listy wymagań (ale w metodyce zorientowanej na produkty i 
> odpowiedzialność a nie jakieś mapy procesików na bazie idiotycznych ankiet)
> - symulacją czy planowany system ma szanse przynieść oczekiwane korzyści 
> biznesowe (ile jest sens na niego wydać by był rentowny)

Tak, ale jak się ustrzec przez nadmiernym chciejstwem użytkownika. A ma 
on tendencję do uwypuklania rzeczy trudnych acz rzadko potrzebnych 
zamiast sytuacji masowych. Dzieje się tak, gdyż pracownicy do tego co 
częste się przyzwyczaili a przed nieznanym strach.

> 
> Z mojej praktyki wynika, że z pierwotnych szczegółowych map procesów na 
> bazie ankiet po wdrożeniu zostaje niewiele więc po co to robić? Do 
> zrozumienia firmy wystarczy jej model procesowy wykonany na bazie metodyki 
> produkt: zobowiązanie-odpowiedzialność.

Jeżeli to znaczy to samo co dostawca - odbiorca informacji to się zgadzam.
> 
> Pracochłonność każdego etapu zależy tylko od zakresu projektu, nie musi 
> trwać w cale roku ale w trzy dni także nie wierzę, nawet gdyby to było 
> wdrożenie samokopiującego bloczka do fakturowania.
Z tym bloczkiem to chyba przesada. Po pierwsze część komputeryzacji 
dokonuje się przy pomocy Excela, a dla mnie to żadna komputeryzacja 
tylko kolorowanie filmu czarno-białego. Po drugie nie należy popadać w 
przesadę. I to jest tym groźniejsze, że niewiele osób o tym mówi. Każde 
rozwiązanie, podkreślam  KAŻDE, nadaje się tylko do określonego 
przedziału zagadnień, przedziału z ograniczeniem górnym i dolnym. Może 
być za duże lub za małe. Dotyczy to również metod analizy. Są przypadki 
w którym skutecznie można zastosować analizę sprowadzoną do rozmowy z 
właścicielem, a są takie w których należy dokonać symulacji w warunkach 
zbliżonych do naturalnych (im większy projekt tym symulacja kosztowniejsza).

I jeszcze jedno. 90% problemów powodowanych jest przez 10%zdarzeń. A 
może 99% powodowanych przez 1%. I dobra analiza powinna to 
identyfikować. Tyle że jest to marzenie ściętej głowy. Choćby dlatego, 
że są to problemy przyszłe, które dopiero wystąpią.

> 
> Jedyne wytłumaczenie tak krótkiej analizy to wdrożenie z czapki gotowego 
> systemu na zasadzie: Państwo od teraz pracujecie tak jak robi to ten 
> program.

Pewnie niektórzy się obruszą, ale w takim podejściu celują duże i 
markowe systemy firm zachodnich (pierwsza dziesiątka dostawców ERP) i 
ci, którzy mają podobne aspiracje. I to mimo dokładnej i kosztownej 
analizy. To oni narzucają formę pracy zarówno pracownikom jak i firmom 
współpracującym. Natomiast niewielkie firmy komputerowe muszą spełniać 
wszystkie wymagania, potrzeby i fanaberie klienta. I to bez analizy, bo 
właśnie pojawiła się nowa możliwość biznesowa i program powinien ją mieć.



Darek

DarekM <darekm@emadar.com> napisal:
> I jeszcze jedno. 90% problemów powodowanych jest przez 10%zdarzeń. A 
> może 99% powodowanych przez 1%. I dobra analiza powinna to 
> identyfikować. Tyle że jest to marzenie ściętej głowy. Choćby dlatego, 
> że są to problemy przyszłe, które dopiero wystąpią.

Cos Ci sie chyba poplatalo z Pareto ;)
-- 
Pozdrawiam,

Jacek

Jacek Pietraszek napisał(a):
> DarekM <darekm@emadar.com> napisal:
>> I jeszcze jedno. 90% problemów powodowanych jest przez 10%zdarzeń. A 
>> może 99% powodowanych przez 1%. I dobra analiza powinna to 
>> identyfikować. Tyle że jest to marzenie ściętej głowy. Choćby dlatego, 
>> że są to problemy przyszłe, które dopiero wystąpią.
> 
> Cos Ci sie chyba poplatalo z Pareto ;)
Nie poplątało, właśnie to ma tu zastosowanie, tyle że nie mierzyłem tego 
dokładnie więc podaję trochę rozmyte wyniki,
Darek

Użytkownik "Franek B" <balabanf@wpREMOVE-ME.pl> napisał w wiadomości 
news:eh79e5$all$1@nemesis.news.tpi.pl...
[...
> Moje spostrzeżenie:
> Firmy "komputerowe" najbardziej brzydzą się analizą i testowaniem
> (a są to przecież najważniejsze i najciekawsze etapy wdrożenia).
> Dlaczego tak jest? Może ktoś potrafi wytłumaczyć bliżej ten
> mechanizm.

Potwierdzam to, moim zdaniem prosta jest tego przyczyna: nie potrafią 
prowadzic analiz i wymigują sie od tego, po drugie jednak często (i tu koło 
sie zamyka) mało którzy klienci rozumieją i akceptują fakt, że wdrożenie bez 
analizy jest bardzo ryzykowne i nie chcą płacić za analiy (pracowałem kiedyś 
w firmie IT, pierwszą rzeczą, którą skreśla zamawiajcy z budżetu jest 
właśnie analiza biznesowa i systemowa).

Więc w pewnym sensie wielu ma porażke na własne rzyczenie. Jest jednak 
światełko w tunelu: firmy które przejechały się na nieudanym projekcie 
zamawiają analizy :)


-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał w 
wiadomości news:eh7e47$hvh$1@opal.futuro.pl...
> [...]
>> Moje spostrzeżenie:
>> Firmy "komputerowe" najbardziej brzydzą się analizą i testowaniem
>> (a są to przecież najważniejsze i najciekawsze etapy wdrożenia).
>> Dlaczego tak jest? Może ktoś potrafi wytłumaczyć bliżej ten
>> mechanizm.
>>
>
> Cięcie kosztów. Nie można zrezygmować z kodowania (produkt musi powstać) i 
> wdrożenia (klient musi coś dostać, żeby zapłacił). Pozostaje analiza, 
> projekt i testowanie - rzeczywiście najciekawsze fragmenty.

To się po prostu nazywa zupełne lekceważenie zarządzania rykiem. I robią to 
właśnie firmy IT mające podobno profesjonalnych PMów.........  ale krótko 
terminowe zyski biorą często górę nad długoterminowymi korzyściami.


-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

Użytkownik "Jacek Pietraszek" <nobody@nospam.cyf-kr.edu.pl> napisał w 
wiadomości news:eh7ff5$rkl$1@srv.cyf-kr.edu.pl...
> Niekompetencja tychze prezesow, ktorzy slyszac o analizie, projekcie
> itd. stwierdzaja, ze placa wylacznie za program, a nie za kilkadziesiat
> kartek, ktore "wicie, rozumicie" nikomu potrzebne nie sa.
> Jak z kolei koszty analizy i porzadnego projektu wsadzisz w produkt
> koncowy, to przegrywasz z krzakiem, ktory dziala w stylu
> "jak daja, to brac, jak bija, uciekac".
>
Niestety prawda ale takich własnei lubię.

> Co wiec pozostaje, jak nie zamierzasz zmieniac branzy?
> Poslugiwac sie gotowcem, z gory zakladajac jakos "good enough",
> albo wyjazd z Polski :)

Trzymać jakość pracy. Ja lubię np. odsyłać firmy do konkurentów. Mówię im, 
że bez analizy palcem nie kiwnę. Jedni zostają inny idą do konkurentów. 
kilku już wróciło....


-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

Użytkownik "DarekM" <darekm@emadar.com> napisał w wiadomości 
news:eh89it$rso$1@node5.news.atman.pl...
[...]
>> Z mojego życia:
>> - brak dobrej analizy to główny powód porażek wdrożeń
> Dobra analiza nie jest zła, tyle że nie wiadomo kiedy była dobra. Są udane 
> wdrożenia po złej analizie i nieudane po dobrej. Bynajmniej nie umniejszam 
> znaczenia analizy, tylko tłumaczę przyczynę nieufności.

Mówiąc o anaizie nie mam na myśłi jej wersji pisanej zawsze, mały projekt 
jest w stanie wykonać nawet jeden dobry proramista analityk ale on i tak 
taką anlize wykonuje "w głowie" w trakcie rozmów. Jednak zebranie wymagań i 
zamiana ich na projekt systemu to nic innego jak analiza.


>
>> - brak modelu firmy i modelu systemu jako narzędzia do testowania hipotez 
>> to kolejna przyczyna porażek
> a czy jest możliwe utworzenie takiego modelu bez papieru i komputera, bo 
> moim zdaniem jest

Owszem, jednak od pewnego stopnia złożoności to za mało, po drugie jeżeli 
zespól liczy więcej niż jedną osobę to przydało by się dokumkentować swoje 
przemyślenia, po trzecie dobrym zwyczajem i kompetencją dobrego analityka 
jest umieć zostawić po sobie swoje przemyślenia w udkumentowanej postaci i 
zrozumiałej dla innych ludzi. Wystarczy mała rotacja ludzi w zespole i jest 
kicha. Brak dokumentacji to prośba o kłopoty.

Kolejna rzecz: wyobraź sobie, że po Tobie przycodzi do Twojego klienta inny 
specjalista, i jak skorzysta z Twojej pracy za którą klient już raz 
zapłacił?

>
>> - możliwe jest dobre wdrożenie parametryzowanego systemu pod warunkiem, 
>> że ma to sens w warunkach danej firmy (i tu pole do popisu dla analityków 
>> biznesowych), system taki jednak powinien pozwalać na modyfikowanie 
>> procesów jakie ma wbudowane  taki system
> to chyba jest masło maślane, wg mnie tu napisałeś: możliwe jest wdrożenie 
> programu który nadaje się do danej firmy

Może zapętliłem: moim zdaniem wdrożenie czegokolwiek w firmie ma sens, 
jeżeli pomoże jej na rynku zabiać więcej (podniesie jej konkurencyjność) bo 
inaczej po co wydawac na system pieniądze? (kto sie bawi w analize 
rentowności wdrożenia IT? Jak tak) Systemy parametryzowalne są różne, ich 
możliwości dopasowania są prawie zawsze ograniczone. Raz więc ma ten bój 
sens a raz nie. Tu jest pole do popisu: wybrać system gotowy czy zlecić 
napisanie dedykowanego. To pytanie można też parafrazować: upodobnić firmę 
do konkurentów czy zachować różnice dające pewnie przewagę nad konkurentami. 
W tym momencie jest miejsce na analize wykonywalności w kontekscie 
biznesowym, przecież system ERP do niczego innego nie służy jak tylko do 
podnoszenia efektywności biznesu.. no niektórym także do wyciągania kasy za 
wdrożenia...:(

>> Każde wdrożenie powinno być poprzedzone:
>> - analiza biznesową
>> - wykonaniem modelu informatyzowanej firmy
>> - wykonaniem listy wymagań (ale w metodyce zorientowanej na produkty i 
>> odpowiedzialność a nie jakieś mapy procesików na bazie idiotycznych 
>> ankiet)
>> - symulacją czy planowany system ma szanse przynieść oczekiwane korzyści 
>> biznesowe (ile jest sens na niego wydać by był rentowny)
>
> Tak, ale jak się ustrzec przez nadmiernym chciejstwem użytkownika. A ma on 
> tendencję do uwypuklania rzeczy trudnych acz rzadko potrzebnych zamiast 
> sytuacji masowych. Dzieje się tak, gdyż pracownicy do tego co częste się 
> przyzwyczaili a przed nieznanym strach.
>

Prawda, tu tylko wzajemne zrozumienie leczy sprawę. Analiza i komunikacja z 
zamawiającym.


>>
>> Z mojej praktyki wynika, że z pierwotnych szczegółowych map procesów na 
>> bazie ankiet po wdrożeniu zostaje niewiele więc po co to robić? Do 
>> zrozumienia firmy wystarczy jej model procesowy wykonany na bazie 
>> metodyki produkt: zobowiązanie-odpowiedzialność.
>
> Jeżeli to znaczy to samo co dostawca - odbiorca informacji to się zgadzam.

Coś w tym sensie własnie :), dodał bym jeszcze miarę każdego tego efektu. 
Znam zapis wymagań w postaci: "system ERP ma udostęniac raport sprzedaży 
możliwie szybko" (zapis stworzony pzrez pewną zacną firmę doradczą z 
Krakowa). Mamy nadawcę i odbiorce informacji ale co z tego? CO to znaczy 
"możłiwie szybko" tu potrzebne jest zobowiązanie (np. raport w ciągu maks. 
15 sekund, nalezy umieć wycenić takie wymaganie żeby podjąc decyzje czy 
warto płacić za 15 sek, bo może wystarczy tańsze 30 )



>>
>> Pracochłonność każdego etapu zależy tylko od zakresu projektu, nie musi 
>> trwać w cale roku ale w trzy dni także nie wierzę, nawet gdyby to było 
>> wdrożenie samokopiującego bloczka do fakturowania.
> Z tym bloczkiem to chyba przesada. Po pierwsze część komputeryzacji 
> dokonuje się przy pomocy Excela, a dla mnie to żadna komputeryzacja tylko 
> kolorowanie filmu czarno-białego. Po drugie nie należy popadać w przesadę. 
> I to jest tym groźniejsze, że niewiele osób o tym mówi. Każde rozwiązanie, 
> podkreślam  KAŻDE, nadaje się tylko do określonego przedziału zagadnień, 
> przedziału z ograniczeniem górnym i dolnym. Może być za duże lub za małe. 
> Dotyczy to również metod analizy. Są przypadki w którym skutecznie można 
> zastosować analizę sprowadzoną do rozmowy z właścicielem, a są takie w 
> których należy dokonać symulacji w warunkach zbliżonych do naturalnych (im 
> większy projekt tym symulacja kosztowniejsza).
>
> I jeszcze jedno. 90% problemów powodowanych jest przez 10%zdarzeń. A może 
> 99% powodowanych przez 1%. I dobra analiza powinna to identyfikować. Tyle 
> że jest to marzenie ściętej głowy. Choćby dlatego, że są to problemy 
> przyszłe, które dopiero wystąpią.
>

Prawda, ale jeżeli jest szansa na obnieżenie ryzyka porażki proektu to moim 
zdaniem trzeba próbować.

>>
>> Jedyne wytłumaczenie tak krótkiej analizy to wdrożenie z czapki gotowego 
>> systemu na zasadzie: Państwo od teraz pracujecie tak jak robi to ten 
>> program.
>
> Pewnie niektórzy się obruszą, ale w takim podejściu celują duże i markowe 
> systemy firm zachodnich (pierwsza dziesiątka dostawców ERP) i ci, którzy 
> mają podobne aspiracje. I to mimo dokładnej i kosztownej analizy. To oni 
> narzucają formę pracy zarówno pracownikom jak i firmom współpracującym. 
> Natomiast niewielkie firmy komputerowe muszą spełniać wszystkie wymagania, 
> potrzeby i fanaberie klienta. I to bez analizy, bo właśnie pojawiła się 
> nowa możliwość biznesowa i program powinien ją mieć.

Zgadzam się w 100%, dla dużego dostawcy IT do przemysł i rzemiosło. Dla duży 
Paradoks polega na tym że wiele firm straciło na takich wdrożeniach straciło 
cały swój rynkowy indywidualizm. I dobrze, jest pole do popisu dla dostawców 
tych firm, które mają większe ambicje niż tylko kopiowanie "modeli 
referencyjnych" czy "najlepszych praktyk". Owszem, nie należy powielać 
cudzych błędów ale to nie ma nic wspólnego z małpowaniem konkurentów.



-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

Jarosław Żeliński napisał(a):
> Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał w 
> wiadomości news:eh7e47$hvh$1@opal.futuro.pl...
> 
>>[...]
>>
>>>Moje spostrzeżenie:
>>>Firmy "komputerowe" najbardziej brzydzą się analizą i testowaniem
>>>(a są to przecież najważniejsze i najciekawsze etapy wdrożenia).
>>>Dlaczego tak jest? Może ktoś potrafi wytłumaczyć bliżej ten
>>>mechanizm.
>>>
>>
>>Cięcie kosztów. Nie można zrezygmować z kodowania (produkt musi powstać) i 
>>wdrożenia (klient musi coś dostać, żeby zapłacił). Pozostaje analiza, 
>>projekt i testowanie - rzeczywiście najciekawsze fragmenty.
> 
> 
> To się po prostu nazywa zupełne lekceważenie zarządzania rykiem. I robią to 
> właśnie firmy IT mające podobno profesjonalnych PMów.........  ale krótko 
> terminowe zyski biorą często górę nad długoterminowymi korzyściami.
> 
> 

Oczywiście że się chce, aby każdy klient został docelowo stałym klientem 
firmy. Ale jeżeli nie widać szans na stałą współpracę i staje się przed 
wyborem zarobić raz lub nie zarobić to czemu rezygnować z punktu 2?

Tym bardziej, że jak klient przekona się, że za porządne wdrożenie 
należy się porządna zapłata, to kolejnym razem będzie można 
przeprowadzić tą ciekawą analizę i testowanie.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał w 
wiadomości news:ehi7ds$r83$1@opal.futuro.pl...
[...]
>> To się po prostu nazywa zupełne lekceważenie zarządzania rykiem. I robią 
>> to właśnie firmy IT mające podobno profesjonalnych PMów.........  ale 
>> krótko terminowe zyski biorą często górę nad długoterminowymi 
>> korzyściami.
>>
>>
>
> Oczywiście że się chce, aby każdy klient został docelowo stałym klientem 
> firmy. Ale jeżeli nie widać szans na stałą współpracę i staje się przed 
> wyborem zarobić raz lub nie zarobić to czemu rezygnować z punktu 2?
>

Żeby nie wstydzic sie punktu 1.



> Tym bardziej, że jak klient przekona się, że za porządne wdrożenie należy 
> się porządna zapłata, to kolejnym razem będzie można przeprowadzić tą 
> ciekawą analizę i testowanie.

Już u innego klienta, którego trzeba będzie drogo pozyskać od zera, 
zakładając, że nie zna on innych naszych klientów zaliczonych tylko punktem 
2 ... a świat jest niestety bardzo mały.......


-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

Jarosław Żeliński napisał(a):
> Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał w 
> wiadomości news:ehi7ds$r83$1@opal.futuro.pl...
> [...]
> 
>>>To się po prostu nazywa zupełne lekceważenie zarządzania rykiem. I robią 
>>>to właśnie firmy IT mające podobno profesjonalnych PMów.........  ale 
>>>krótko terminowe zyski biorą często górę nad długoterminowymi 
>>>korzyściami.
>>>
>>>
>>
>>Oczywiście że się chce, aby każdy klient został docelowo stałym klientem 
>>firmy. Ale jeżeli nie widać szans na stałą współpracę i staje się przed 
>>wyborem zarobić raz lub nie zarobić to czemu rezygnować z punktu 2?
>>
> 
> 
> Żeby nie wstydzic sie punktu 1.
> 
> 

Nie rozumiem. Zawsze powinno się proponować analizę - tu się zgadzamy. 
Ale jeżeli klient nie chce żadnych papierów i wogóle domaga się produktu 
za pół ceny, to czy trzeba od razu rezygnować z takiego 
nieuświadomionego klienta?

> 
> 
>>Tym bardziej, że jak klient przekona się, że za porządne wdrożenie należy 
>>się porządna zapłata, to kolejnym razem będzie można przeprowadzić tą 
>>ciekawą analizę i testowanie.
> 
> 
> Już u innego klienta, którego trzeba będzie drogo pozyskać od zera, 
> zakładając, że nie zna on innych naszych klientów zaliczonych tylko punktem 
> 2 ... a świat jest niestety bardzo mały.......
> 
> 

Nie pracuję w marketingu, więc mogę się mylić. Ale rozumuję tak: jeżeli 
klientowi wytłumaczy się koszta rezygnacji z analizy na początku to jest 
szansa, że zrozumie iż nieudane wdrożenie wynika z wdrażania na siłę 
przy zbyt ograniczonym budżecie.

Wiadomo, niektórzy będą na siłę szukać przyczyn porażki poza sobą - i ci 
klienci mogą robić zły marketing. Dlatego lepiej zrezygnować z klienta, 
który skąpi na analizę, jeśli tylko można. Z drugiej strony, jeżeli 
wdrożenie bez analizy się uda, to się ma klienta więcej + darmową 
reklamę. Także dla mnie wybór nie jest zerojedynkowy.

Tym bardziej, że na rynku utrzymują się zarówno producenci markowej 
odzieży jak i Wietnamczycy:-)

Pozdrawiam


-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał w 
wiadomości news:ehii1h$gng$1@opal.futuro.pl...
[...]
> Nie rozumiem. Zawsze powinno się proponować analizę - tu się zgadzamy. Ale 
> jeżeli klient nie chce żadnych papierów i wogóle domaga się produktu za 
> pół ceny, to czy trzeba od razu rezygnować z takiego nieuświadomionego 
> klienta?
>

Ja w takich przypadkach wpisuje do kwitów jako ograniczenie i czynnnik 
ryzyka projektu brak analizy.


[...]
> Nie pracuję w marketingu, więc mogę się mylić. Ale rozumuję tak: jeżeli 
> klientowi wytłumaczy się koszta rezygnacji z analizy na początku to jest 
> szansa, że zrozumie iż nieudane wdrożenie wynika z wdrażania na siłę przy 
> zbyt ograniczonym budżecie.

To zawsze (no często) jest tak:
Idzie pacjent do lekarza i mówi, że boli go w sobie. Lejarz na to: zaczniemy 
więc od prześwietlenia płuc i usg jamy brzusznej. Klient odmawia jednak 
kosztów badań. Lekarz zapisuje się więc Apap lub Aspirynę. Pacjent zmarł po 
kwartale a rodzina wszędzie rozpowiada, że lekarz to gnojek i nieuk, że wiął 
forsę za leczenie a szwagiej i tak sie przekręcił.

Ja odmawiam przyjęcia zlecenia, chyba że przyjmą w treści opracowania 
napisane wołami: Ograniczenia zwiazane z analizą wymagń i tu stosowna 
laurka. Niektózy nie chce takiego tekstu a ja odpuszczam.



>
> Wiadomo, niektórzy będą na siłę szukać przyczyn porażki poza sobą - i ci 
> klienci mogą robić zły marketing. Dlatego lepiej zrezygnować z klienta, 
> który skąpi na analizę, jeśli tylko można. Z drugiej strony, jeżeli 
> wdrożenie bez analizy się uda, to się ma klienta więcej + darmową reklamę. 
> Także dla mnie wybór nie jest zerojedynkowy.

No to jest po protu :) loteria ....

>
> Tym bardziej, że na rynku utrzymują się zarówno producenci markowej 
> odzieży jak i Wietnamczycy:-)
>

I wybór należy do Ciebie :)

-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

Jarosław Żeliński napisał(a):
> Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał w 
> wiadomości news:ehii1h$gng$1@opal.futuro.pl...
> [...]
> 
>>Nie rozumiem. Zawsze powinno się proponować analizę - tu się zgadzamy. Ale 
>>jeżeli klient nie chce żadnych papierów i wogóle domaga się produktu za 
>>pół ceny, to czy trzeba od razu rezygnować z takiego nieuświadomionego 
>>klienta?
>>
> 
> 
> Ja w takich przypadkach wpisuje do kwitów jako ograniczenie i czynnnik 
> ryzyka projektu brak analizy.
> 

Chyba też zacznę. Dzięki za pomysł.


-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Jarosław Żeliński napisał(a):
> Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał w 
> wiadomości news:ehii1h$gng$1@opal.futuro.pl...
> [...]
> 
>>Nie rozumiem. Zawsze powinno się proponować analizę - tu się zgadzamy. Ale 
>>jeżeli klient nie chce żadnych papierów i wogóle domaga się produktu za 
>>pół ceny, to czy trzeba od razu rezygnować z takiego nieuświadomionego 
>>klienta?
>>
> 
> 
> Ja w takich przypadkach wpisuje do kwitów jako ograniczenie i czynnnik 
> ryzyka projektu brak analizy.
> 
[...]

Chyba też tak zacznę :-). Dzięki za radę.

Chociaż spotykałem się z sytuacją, że jak się mówi o ryzyku z powodu 
zaniechania analizy, to klient nie chce rezygnować, a koszty trzeba 
ciąć. Więc zaczynało się oficjalnie mówić o "uproszczonej analizie" czy 
innym tym podobnym kwiatku językowym. Czyli o "prawie analizie", gdzie 
prawie robi wielką różnicę :-).

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

[...]

> - wykonaniem listy wymagań (ale w metodyce zorientowanej 
> na produkty i odpowiedzialność a nie jakieś mapy procesików 
> na bazie idiotycznych ankiet)

Zbieranie wymagań nie polega na rysowaniu map procesów.

"Franek B" <balabanf@wpREMOVE-ME.pl> writes:

[...]

> Firmy "komputerowe" wymigują się od modyfikacji gotowców.

Z drugiej strony: istnieje oprogramowanie, którego można użyć 
do zarządzania wieloma wersjami i konfiguracjami oferowanego
oprogramowania.

Piotr Dembiński napisał(a):
> "Franek B" <balabanf@wpREMOVE-ME.pl> writes:
> 
> [...]
> 
> 
>>Firmy "komputerowe" wymigują się od modyfikacji gotowców.
> 
> 
> Z drugiej strony: istnieje oprogramowanie, którego można użyć 
> do zarządzania wieloma wersjami i konfiguracjami oferowanego
> oprogramowania.

Co nie zmienia faktu, że zarządzanie wersjami i konfiguracjami kosztuje.

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości 
news:87fyd23nw9.fsf@hector.domek...
> "Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:
>
> [...]
>
>> - wykonaniem listy wymagań (ale w metodyce zorientowanej
>> na produkty i odpowiedzialność a nie jakieś mapy procesików
>> na bazie idiotycznych ankiet)
>
> Zbieranie wymagań nie polega na rysowaniu map procesów.

I tu bym polemizował.

-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

Piotr pisze:
> Zbieranie wymagań nie polega na rysowaniu map procesów.

Coś rysować jednak trzeba. Otwarta głowa, papier i ołówek
są niezastąpione przy zbieraniu wymagań. Ale tego właśnie
boją się firmy nastawione na sprzedaż gotowców. Porządnie
przeprowadzona analiza nieuchronnie prowadziłaby do jednego
z wniosków:
  - gotowiec wymaga znacznej rozbudowy, modyfikacji
    istniejącego kodu i struktur danych (w najlepszym razie
    może być użyty jako prototyp rzędu zerowego),

  - gotowiec nie nadaje się do wdrożenia.

Nie zdarzy się tak, że gotowiec jest "w sam raz" (mam na
myśli system dla przedsiębiorstwa przemysłowego, a nie dla
sklepu z odzieżą używaną). Pisałem już wyżej o micie
"powielarności systemów". Jeżeli bez przeprowadzenia analizy
firma twierdzi, że wie lepiej, czego potrzebuje klient, to
znaczy, że nie wie nic.

Uwaga na bajer:
"Wraz z systemem sprzedajemy wam wiedzę biznesową (know-how)".

Dają się na to nabierać prezesi przedsiębiorstw przemysłowych,
ktorzy też woleliby uniknąć precyzyjnego określenia, czego
właściwie potrzebują, czyli uniknąć analizy (wdrażamy system,
bo "inni" już mają, więc wypada mieć). Potem w okresie
eksploatacji okazuje się, nie dość że sypiący się system
nie tylko nie wnosi żadnego "know-how", to sam wymaga szerokiego
wsparcia ze strony Clippera i dodatkowej ewidencji ręcznej.

BTW
Naukowcy wymyślają różne metodyki analizy. Toczą zażarte spory
o to, które z nich (strukturalne czy obiektowe?) i w jakich
okolicznościach są lepsze. Według mnie w każdym przypadku lepsza
jest którakolwiek niż żadna.

Pozdrawiam
-- 
   Franciszek Bałaban

> Nie zdarzy się tak, że gotowiec jest "w sam raz" (mam na
> myśli system dla przedsiębiorstwa przemysłowego, a nie dla
> sklepu z odzieżą używaną). Pisałem już wyżej o micie
> "powielarności systemów". 

TO zależy jak podchodzimy do systemów. Czy tak jak do budowania domu 
(każdy wg nowego projektu) czy też tak jak do samochodu czyli produkcja 
pośrednia. Oczywiście każde z podejść dąży do osiągnięcia zalet 
konkurencyjnego przy zachowaniu własnych ale należy pamiętać w którym 
miejscu jesteśmy i który model wybieramy.

Jeżeli bez przeprowadzenia analizy
> firma twierdzi, że wie lepiej, czego potrzebuje klient, to
> znaczy, że nie wie nic.
Zgoda, tak samo jak to że klient wie lepiej co potrzebuje. W trakcie 
analizy, przeglądania ofert klient się uczy i precyzuje/rozwija swoje 
potrzeby/chciejstwo a analityk poznaje firmę.

> 
> Uwaga na bajer:
> "Wraz z systemem sprzedajemy wam wiedzę biznesową (know-how)".
> 
> Dają się na to nabierać prezesi przedsiębiorstw przemysłowych,
> ktorzy też woleliby uniknąć precyzyjnego określenia, czego
> właściwie potrzebują, czyli uniknąć analizy (wdrażamy system,
> bo "inni" już mają, więc wypada mieć). 
Wiele słabych osób wybiera markę jako substytut jakości.




Potem w okresie
> eksploatacji okazuje się, nie dość że sypiący się system
> nie tylko nie wnosi żadnego "know-how", to sam wymaga szerokiego
> wsparcia ze strony Clippera i dodatkowej ewidencji ręcznej.
> 
To dotyczy również najbardziej renomowanych systemów. A systemy 
dedykowane mają to do siebie że co prawda rozwiązują główne potrzeby 
klienta lecz nie posiadają pewnych, rzadko przydatnych drobiazgów w 
stylu adresowanie kopert, naliczanie odsetek czy automatyczne wybieranie 
  numeru telefonu. Programy uniwersalne załatwiają część z tych 
elementów dzięki czemu klient ma więcej czasu na  obsługę zadań 
podstawowych nawet topornymi narzędziami.



Darek

Dnia Thu, 02 Nov 2006 09:11:30 +0100, Grzesiek G. skrobie:
> Piotr Dembiński napisał(a):
> > "Franek B" <balabanf@wpREMOVE-ME.pl> writes:
> > 
> > [...]
> > 
> > 
> >>Firmy "komputerowe" wymigują się od modyfikacji gotowców.
> > 
> > 
> > Z drugiej strony: istnieje oprogramowanie, którego można użyć 
> > do zarządzania wieloma wersjami i konfiguracjami oferowanego
> > oprogramowania.

> Co nie zmienia faktu, że zarządzanie wersjami i konfiguracjami kosztuje.

Owszem, i to nie tylko w narzędziach.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

> Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał
> w wiadomości news:87fyd23nw9.fsf@hector.domek...
>> "Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:
>>
>> [...]
>>
>>> - wykonaniem listy wymagań (ale w metodyce zorientowanej
>>> na produkty i odpowiedzialność a nie jakieś mapy procesików
>>> na bazie idiotycznych ankiet)
>>
>> Zbieranie wymagań nie polega na rysowaniu map procesów.
>
> I tu bym polemizował.

Oczywiście można zdefiniować wymagania na podstawie modelu
przedsiębiorstwa, ale tworzenie modelu przedsiębiorstwa nie wchodzi
w skład samego procesu zbierania wymagań.

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

> Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał
> w wiadomości news:87fyd23nw9.fsf@hector.domek...
>> "Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:
>>
>> [...]
>>
>>> - wykonaniem listy wymagań (ale w metodyce zorientowanej
>>> na produkty i odpowiedzialność a nie jakieś mapy procesików
>>> na bazie idiotycznych ankiet)
>>
>> Zbieranie wymagań nie polega na rysowaniu map procesów.
>
> I tu bym polemizował.

Oczywiście można zdefiniować wymagania na podstawie modelu
przedsiębiorstwa, ale opracowanie modelu przedsiębiorstwa nie wchodzi
w skład samego procesu zbierania wymagań.

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości 
news:874ptg257c.fsf@hector.domek...
[...]
> Oczywiście można zdefiniować wymagania na podstawie modelu
> przedsiębiorstwa, ale opracowanie modelu przedsiębiorstwa nie wchodzi
> w skład samego procesu zbierania wymagań.

Owszem. Jednak jest to jedna z najskuteczniejszych metod dająca małe ryzyko 
pominięcia ważnych rzeczy. Zakup i użycie młotka nie wchodzi w zakres 
projektu "wykonanie stołu" jednak bardzo często ten młotek jest w użyciu 
jako narzędzie mimo, że po wykonaniu stołu nie raz ląduje na strychu. :)





-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

> Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał
> w wiadomości news:874ptg257c.fsf@hector.domek...
> [...]
>> Oczywiście można zdefiniować wymagania na podstawie modelu
>> przedsiębiorstwa, ale opracowanie modelu przedsiębiorstwa nie
>> wchodzi w skład samego procesu zbierania wymagań.
>
> Owszem. Jednak jest to jedna z najskuteczniejszych metod dająca małe
> ryzyko pominięcia ważnych rzeczy. Zakup i użycie młotka nie wchodzi
> w zakres projektu "wykonanie stołu" jednak bardzo często ten młotek
> jest w użyciu jako narzędzie mimo, że po wykonaniu stołu nie raz
> ląduje na strychu. :)

No tak, ale ty chciałeś połączyć analizę (to, jak już jest)
z projektowaniem (to, jak chcemy, żeby było w przyszłości).

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości 
news:87r6we9ifj.fsf@hector.domek...
>> Owszem. Jednak jest to jedna z najskuteczniejszych metod dająca małe
>> ryzyko pominięcia ważnych rzeczy. Zakup i użycie młotka nie wchodzi
>> w zakres projektu "wykonanie stołu" jednak bardzo często ten młotek
>> jest w użyciu jako narzędzie mimo, że po wykonaniu stołu nie raz
>> ląduje na strychu. :)
>
> No tak, ale ty chciałeś połączyć analizę (to, jak już jest)
> z projektowaniem (to, jak chcemy, żeby było w przyszłości).

Owszem. Ogólnie zaczęło się  od wymagań, ale aby je opisać uważam, ze 
potrzebna jest analiza. A modelowanie traktuję nie jako cel sam w sobie a 
jako narzędzie analizy (systemowej).

Przecież wielu z nas używa żółtych karteczek na ścianach, wywiadów, 
warsztatów itp. To nic innego jak narzędzia pracy. Model firmy to także 
narzędzie. W przypadku projektowania podobnie. Przecież krawiec jak 
projektuje i wykonuje garnitur to nieodłącznym elementem jego warsztatu jest 
manekin, który mu zastępuje w codziennej pracy zamawiającego. To jest 
właśnie model. Krawiec musi zdobyć manekina o wymiarach takich jak 
zamawiający i z jego pomocą projektuje i wykonuje garnitur. Można oczywiście 
uszyć garnitur tylko na podstawie pobranych miar i rozmów ale tak właśnie 
wygląda wiele dzisiejszych systemów IT :)

Podkreślam: to moja opinia o projektowaniu. Nie zapominajmy, że projektujemy 
system IT a nie firmę! Firma jest (lub manekin) a program trza zaprojektować 
i wykonać (garnitur). Jak nie ma manekina to moim zdaniem lepiej go zrobić 
bo to bardzo obniża ryzyko porażki.




-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

[...]

> Przecież krawiec jak projektuje i wykonuje garnitur to nieodłącznym
> elementem jego warsztatu jest manekin, który mu zastępuje
> w codziennej pracy zamawiającego. To jest właśnie model. 

Nie rozumiem tej analogii.

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości 
news:87r6wc8qva.fsf@hector.domek...
> "Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:
>
> [...]
>
>> Przecież krawiec jak projektuje i wykonuje garnitur to nieodłącznym
>> elementem jego warsztatu jest manekin, który mu zastępuje
>> w codziennej pracy zamawiającego. To jest właśnie model.
>
> Nie rozumiem tej analogii.

Hm... jeżeli mamy do zaprojektowania system dla firmy, np. ERP, to 
projektujemy i wykonujemy system IT a nie firmę. Firma (jej pracownicy) 
będzie go używała. Jednak system jest dla firmy i należy mieć pewność że 
będzie wspierał możliwie najlepiej procesy w tej firmie. Jeżeli za pomocą 
np. UML robimy model to jest to model systemu a nie firmy. Modelujemy 
procesy biznesowe po to by zrobić sobie "opis firmy do celów stworzenia 
systemu IT".

Mając dobry model firmy rozumiemy ją i potrafimy sami rozwiązać wiele 
problemów (spisać wymagania na system) bez stałego zawracania głowy 
pracownikom firmy.  Podobnie jak krawiec mając model (manekin) swojego 
klienta jest w stanie szyć i przymierzać garnitur i nie musi wołać klienta 
co kilka godzin do miary. Bez modelu (nie chciał mieć manekina) będzie 
prosił klienta do miary po każdej poprawce. Wiec mimo, że klient nie 
zamawiał manekina krawiec robiąc drogi garnitur i tak będzie go potrzebował. 
W wielu przypadkach klient nie zgodzi na wizyty dwa razy dziennie a nie 
chcąc mieć źle uszytego garnitur sam poprosi o "wykonanie swojego odlewu" bo 
dzięki temu będzie miał dobry garnitur i nie straci mnóstwa czasu na 
cykliczne przymierzanie.



-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

[...]

> Mając dobry model firmy rozumiemy ją i potrafimy sami rozwiązać
> wiele problemów (spisać wymagania na system) bez stałego zawracania
> głowy pracownikom firmy.  Podobnie jak krawiec mając model (manekin)
> swojego klienta jest w stanie szyć i przymierzać garnitur i nie musi
> wołać klienta co kilka godzin do miary. 

No tak, tylko że -- trzymając się analogii -- krawiec powinien mieć
osobny manekin dla każdego z klientów.

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości 
news:87irhn8asm.fsf@hector.domek...
> "Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:
>
> [...]
>
>> Mając dobry model firmy rozumiemy ją i potrafimy sami rozwiązać
>> wiele problemów (spisać wymagania na system) bez stałego zawracania
>> głowy pracownikom firmy.  Podobnie jak krawiec mając model (manekin)
>> swojego klienta jest w stanie szyć i przymierzać garnitur i nie musi
>> wołać klienta co kilka godzin do miary.
>
> No tak, tylko że -- trzymając się analogii -- krawiec powinien mieć
> osobny manekin dla każdego z klientów.

Dokładnie, jeżeli robię dedykowane garnitury to powinienem wcześniej wykonać 
dedykowanego manekina. Dlatego po wielu porażkach (74% projektów IT to 
wpadki, dane za rok 2004) staje się  regułą ,że:
- tanie garnitury kupujemy gotowe z taśmy i korzystamy z paska do spodni lub 
szelek by nie chodzić na golasa, ale za to wielu ludzi wokół nas ma taki sam 
garnitur i trudno sie "wyróżnić na rynku",
- jak uznamy, że trza nam dobry i dobrze dopasowany najpierw robimy 
manekina, mamy dedykowany garnitur i nasza konkurencyjność wygląda zupełnie 
inaczej :)

Dlatego modelowanie jest coraz częściej wykorzystywane jako element analizy 
przedwdrożeniowej i etapu zbierania wymagań. Są projekty które sa z 
definicji dedykowane, np. hurtownie danych. Tu zakup "gotowca branżowego" 
jest moim zdaniem raczej nieporozumieniem. Coraz częściej każdy większy 
system wymaga "uszycia na miarę". Dlatego rośnie popularność systemów 
będących raczej szkieletem niż gotowcem.



-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

> Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości 
> news:87irhn8asm.fsf@hector.domek...
>> "Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:
>>
>> [...]
>>
>>> Mając dobry model firmy rozumiemy ją i potrafimy sami rozwiązać
>>> wiele problemów (spisać wymagania na system) bez stałego
>>> zawracania głowy pracownikom firmy.  Podobnie jak krawiec mając
>>> model (manekin) swojego klienta jest w stanie szyć i przymierzać
>>> garnitur i nie musi wołać klienta co kilka godzin do miary.
>>
>> No tak, tylko że -- trzymając się analogii -- krawiec powinien mieć
>> osobny manekin dla każdego z klientów.
>
> Dokładnie, jeżeli robię dedykowane garnitury to powinienem wcześniej
> wykonać dedykowanego manekina.

Rozumiem, że chodzi o taki manekin, który porusza się w ten sam sposób
i ma taką samą gestykulację, co osoba, dla której jest szyty garnitur.

Oprócz tego należałoby uwzględnić czynniki środowiskowe: warstwę
społeczną, w której plasuje się odbiorca garnituru, środowisko,
w którym żyje, ludzi, z którymi się spotyka etc.  To tyle, jeśli
chodzi o poszukiwanie analogii.

-- 
http://www.piotr.dembiński.prv.pl

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości 
news:87u014ttn4.fsf@hector.domek...
> "Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:
[...]
> Rozumiem, że chodzi o taki manekin, który porusza się w ten sam sposób
> i ma taką samą gestykulację, co osoba, dla której jest szyty garnitur.
>
> Oprócz tego należałoby uwzględnić czynniki środowiskowe: warstwę
> społeczną, w której plasuje się odbiorca garnituru, środowisko,
> w którym żyje, ludzi, z którymi się spotyka etc.  To tyle, jeśli
> chodzi o poszukiwanie analogii.
>
> -- 
> http://www.piotr.dembiński.prv.pl

Hm.... jest coś takiego jak perspektywa modelowania dlatego u 
profesjonalnego krawca manekin nie musi mieć cech charakteru przyszłego 
właściciela garnituru.


-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

"Jarosław Żeliński" <jarek@zelinski.biz.pl> writes:

[...]

> Hm.... jest coś takiego jak perspektywa modelowania dlatego
> u profesjonalnego krawca manekin nie musi mieć cech charakteru
> przyszłego właściciela garnituru.

Nadal uważam tę analogię za chybioną.