Twierdzenia, że nie da się inaczej, klienci nie wiedzą czego chcą, dokumenty tekstowe to jedyne możliwe opisy wymagań itp. są prostu nie prawdą, to usprawiedliwienia braku kompetencji albo zawyżania kosztów projektów (a raczej pokrywania braku kompetencji pieniędzmi z kieszeni klientów). Pewien znajomy, współwłaściciel pewnej firmy programistycznej, napisał mi niedawno: "korzyści z takiego dokumentowania wymagań są ogromne. Wykonawca, który potrafi pracować na modelach ma 2-3 krotnie niższe koszty i 1,5-4 krotnie krótszy czas wykonania. AMEN TO THIS:)" A co on miał na myśli?
XXV edycja seminarium w cyklu INFORMATYKA KORPORACYJNA
ZARZĄDZANIA ELEKTRONICZNYMI DOKUMENTAMI
25 i 26 maja 2011 w sali kongresowej Biblioteki Narodowej w Warszawie pod tradycyjnym hasłem ?Jakość to ciągle polskie wyzwanie? odbędzie się czwarty Kongres ISO-Poland. Tegoroczna edycja poświęcona jest problematyce dojrzałych wdrożeń ISO w przedsiębiorstwach i instytucjach. W toku dwudniowych obrad podjęte zostaną tematy dotyczące sfery zarządzania, pracy grupowej, obsługi klienta, delegowania władzy, bezpieczeństwa informacji i zarządzania ryzykiem. W programie przewidziano aż cztery fora dyskusyjne, trzy kilkugodzinne warsztaty, liczne wystąpienia ekspertów, autorytetów branży. Po raz pierwszy podjęta zostanie kwestia jakości w życiu publicznym, a także wątek zastosowania warsztatu ISO do ?zarządzania? sferą spraw prywatnych. Gościem specjalnym będzie prof. Andrzej Blikle. Organizatorzy spodziewają się wizyty wicepremiera rządu, ministra gospodarki, Waldemara Pawlaka.
W pierwszych latach prowadziliśmy coś co można by nazwać podstawową agitacją dotyczącą ISO. Udowadnialiśmy, że to dobre rozwiązanie, że warto się zaangażować w jego wdrożenie. Ten etap już za nami. Musimy iść dalej i odnieść się do problemów bardziej zaawansowanych. De facto są to wszystkie problemy zarządzania przedsiębiorstwem. Takich wątków jest wiele. Oczywiście nie jesteśmy w stanie zrobić imprezy, która by mówiła dogłębnie o wszystkim. Staramy się jednak wyłuskiwać tematy najbardziej interesujące i potrzebne. Dodajmy, że konferencje, kongresy, służą przede wszystkim inspirowaniu, przekazywaniu impulsów do myślenia, poszukiwania, dalszego rozwoju. Wychodząc z tego założenia, staramy się żeby uczestnicy wyjeżdżali naładowani nowymi pomysłami i ideami. Aby mieli później ?power? do ich realizacji w swoich przedsiębiorstwach i organizacjach.
Zbiegły się dwa fakty: gorąca dyskusja na forum na temat umiejętności programistów i przy okazji ich roli w procesie wytwarzania oprogramowania oraz przesyłka z kolejną nową książką na moja półkę. Ale po kolei. Najpierw fazy cyklu wytwarzania oprogramowania a potem kilka uwag. Zakupiona książka opisuje całość, ja tu skupie się na jej wstępie. Nie będę jej tłumaczył a jedynie opisze idee. Zwrócę także uwagę na pewne aspekty związane z dostarczaniem gotowego oprogramowania, np. systemów typu ERP lub ich komponentów.
Ogólnie tak zwany rynkowy łańcuch wartości dodanej polega na tym, że na każdym etapie łańcucha dystrybucji powstaje wartość dla następcy. Każdy następca jest klientem swojego poprzednika a ten dostawcą swojego klienta. Jeżeli któreś ogniwo (etap) nie tworzy wartości, jest pomijane (w jakiejś perspektywie).Mając na uwadze powyższe i tę powszechnie powtarzaną zasada "klient nasz Pan", w moich oczach uznawanie jej raczej świadczy o tym, że ktoś nie rozumie swojej roli w tym łańcuchu. Uznając, że to klient jest "naszym Panem" przyznajemy, że nie mamy żadnego wpływu na naszą działalność (sprzedaż). System CRM to narzędzie wspierające budowanie wartości dodanej, jeśli tego nie robi stanowi raczej zbędny koszt.
Celem jest oprogramowanie a dostawcy oprogramowania najmniej ryzykują gdy dostaną jego specyfikuję czyli gotowy projekt. Tak wiec przetestowany model oprogramowania realizujący cel zamawiającego jako wynik analizy systemowej stanowi nic innego jak opis produktu, który ma powstać. Oczywiście nikt nie projektuje od zera oprogramowania biznesowego bo to nierozsądne, wykorzystuje się tak zwane szkielety oprogramowania. O szkieletach już było tu: Frameworks Introduction ? czyli jak się psuje dobre ERP. A teraz zapraszam do obejrzenia tego co tu napisałem po mojemu czyli na diagramie :) (tak zwane mapy myśli czasami sie przydają :)).Warto tu zwrócić uwagę na jedną rzecz: ewentualne zmiany rozwiązania i korekty modelu (czyli projektu) odbywają się nadal na etapie analizy i projektowania, a wiec o rząd albo dwa taniej, niż podczas implementacji. Jest to główna przewaga tej metody nad analizą w postaci sesji [[JAD]] i opracowywania strukturalnych dokumentów.
Te i podobne "zasady" to w moich oczach jakieś oczywistości. Jednak czy złe? Hm.... czasami mam wrażenie, że wielu ludzi faktycznie powinno nawet te oczywistości poznać, z drugiej jednak strony zachodzi ryzyko, że ktoś uwierzy że proste stosowanie ich obligatoryjnie prowadzi do prostych sukcesów a to już jest ślepa uliczka. Ludzie często szukają "złotego środka" na wszystko, tak zwanej "[[srebrnej kuli]]". Nie prostych recept, gdyby istniały nie było by problemów. Każdy problem (wyzwanie) to indywidualny problem w unikalnym środowisku. Jeżeli ktoś daje wiarę w to, że istnieje jakaś recepta na ich rozwiązywanie ...
Analityk systemów to jeden z trudniejszych, ale i lepiej opłacanych zawodów z branży informatycznej. Od jego umiejętności w dużej mierze zależy sukces rynkowy przedsiębiorstwa, które korzysta z jego usług. (źr. Analityk systemów - NEXT 10/2008 - Artykuły - NEXT).
Mamy pewien konflikt interesów: nabywca technologii IT chce coś "na już i na krótko" a dostawcy technologii IT, mający inną strukturę kosztów, dążą do długoterminowych kontraktów. Jak sobie z tym poradzić? Dostawcy IT w zasadzie nie mają wyjścia, muszą iść tropem np. dostawców obrabiarek: szkielet maszyny plus wymienne narzędzia. Jeżeli obrabiarkę można przezbroić w kilka godzin, używając do tego nawet jednorazowo wykonanych narzędzi to samo musi być możliwe w systemie ERP albo będzie on zakałą całego procesu (co niestety nie raz ma miejsce!). Pomimo tego, że maszyny uniwersalne z wymiennymi końcówkami są droższe to jednak ryzyko ich zakupu jest znacznie niższe bo możliwe staje się policzenie kosztu pojedynczego wyrobu. Koszt utrzymania szkieletu takiej maszyny można bezpiecznie rozłożyć ryczałtem podobnie jak koszt budynku czy działów firmy, których istnienie jest wymuszone samym istnieniem firmy (jak np. księgowość).
Tak więc jest miejsce dla zamkniętych, obłożonych licencjami i patentami produktów o długim cyklu życia bo to pieniądze z licencji i supportu dla twórców tego oprogramowania, jest miejsce dla produktów dedykowanych bo tu liczy się zupełnie co innego i spokojnie można tu użyć komponentów OS bo to skraca cykl wytwórczy jednak należy to robić ze zrozumieniem i rozwagą... Próba napisania jednej uniwersalnej aplikacji "do wszystkiego" skończy się kłopotami z prostego powodu: nie da się stworzyć uniwersalnego modelu pojęciowego, który opisywał by za jednym zamachem znane i przyszłe kampanie i produkty...
Za kompletność i jakość dokumentacji projektowej zawsze odpowiada zamawiający i to on musi dostarczyć wykonawcy prawidłowy i wolny od wad projekt. Zauważyłem, że nie wszyscy zamawiający zdają sobie jednak sprawę, że przepisami dotyczącymi rękojmi, a zwłaszcza gwarancji, są objęte także usługi projektowe.
