| Czy oprogramowanie XXXX jest dobre? |
|
Autor: Adres poczty elektronicznej jest chroniony przed robotami spamującymi. W przeglądarce musi być włączona obsługa JavaScript, żeby go zobaczyć. . [Czytelnik] Mam do Pana zupełnie prywatnie pytanie. Jak Pana zdaniem wypada oprogramowanie XXXX w porównaniu z innymi, podobnymi rozwiązaniami tego typu na rynku? Chodzi mi zarówno o poziom cenowy jak i funkcjonalność i możliwości tego systemu?
Autor: Adres poczty elektronicznej jest chroniony przed robotami spamującymi. W przeglądarce musi być włączona obsługa JavaScript, żeby go zobaczyć. . [Czytelnik] Mam do Pana zupełnie prywatnie pytanie. Jak Pana zdaniem wypada oprogramowanie XXXX w porównaniu z innymi, podobnymi rozwiązaniami tego typu na rynku? Chodzi mi zarówno o poziom cenowy jak i funkcjonalność i możliwości tego systemu? [J.Ż.] Nie wiem czy to Pana pocieszy czy zmartwi ale moja praktyka potwierdza jedno: najpierw cel potem narzędzie. Co ciekawe praktyka pokazuje, że nie licząc pewnych specyficznych dla środowiska cech niezmiennych systemu (są to jego ograniczenia), wdrożyć da się każde narzędzie.
2. Prawdziwym procesem jest np. wydanie towaru z magazynu a nie wystawienie kwitu magazynowego z czterem podpisami. ten ostatni jedynie dokumentuje ten fakt. 3. W procesie wydania towaru z magazynu weryfikacja stanu magazynowego jest pośrednią czynnością warunkującą dalsze działania, zmiana liczby zatwierdzających może zoptymalizować cały proces. 4. Szkielet pozwala na zbudowanie potrzebnego oprogramowania, sztywna aplikacja w zasadzie pozwala jedynie nauczyć się instrukcji obsługi i jakoś samodzielnie radzić sobie z kłopotami. 5. Jeżeli szkielet oprogramowania nie pozwala na implementacje modeli (notacji) z analizy to praktycznie oprogramowanie jest niewdrażalne w tej firmie (w pełnym zakresie), innym wyjściem jest użycie do analizy notacji zgodnej z tym szkieletem, wtedy szybko sie okaże czy przyszłe oprogramowanie spełni oczekiwania. 6. drugim elementem jest model danych (potrzeby informacyjne firmy, patrz artyuł pod tym tytułem), oprogramowanie MUSI mieć możliwość jego implementacji, bez tego praktycznie nie nadaje się wdrożenia lub ograniczy możliwości funkcjonowania firmy, w której jest wdrażane! Cena samego narzędzia jest najgorszym parametrem do oceny i porównywania produktów na rynku. Spokojnie może Pan to mówić swoim klientom. Łopata kosztuje grosze w porównaniu z koparką ale nikt przy zdrowych zmysłach nie pyta o łopatę w przetargu na kopanie fundamentów tylko o to ile będzie kosztowało jego wykopanie i ile to potrwa. Dokładnie tego należy uczyć pytających klientów. Rozmawiać z nimi o kopaniu a nie o łopacie. Klient (zamawiający) powinien określić cel projektu a dostawca odpowie jakim kosztem i kiedy go zrealizuje, w takim kontekście dyskusja o kosztach samych licencji spada na drugi a nawet trzeci plan ... ale staje się istotna podczas drugiej części rozmowy: ile kosztuje utrzymanie. Jak widać w zasadzie opisałem "niechcący" cel tworzenia analizy wymagań, pokazałem że pomaga ona w równym stopniu zamawiającemu jak i dostawcy. Widać także to co powinna tak na prawdę obejmować taka analiza wymagań. Gdybym miał coś poradzić od siebie każdemu dostawcy oprogramowania to było by to: - opracuj hipotetyczny plan wdrożenia wraz z kosztami w postaci rachunku przepływów finansowych - uczyń z tego planu uniwersalny model kosztowy wdrożenia (zdefiniuj w postaci parametrów między innymi: koszt licencji, koszt usług wdrożeniowych, koszt sprzętu, koszty utrzymania) - dodaj do tego modelu elementy "przychodu" w postaci oszczędności jakie dana firma odniesie z wdrożenia. Będą to generalnie oczekiwane obniżenie obecnych kosztów oraz wartość dodatkowych korzyści np. dodatkowych przychodów z tytułu poprawy wizerunku firmy. Tak więc mamy dwa elementy analizy: - analiza wymagań - analiza wykonywalności Całość można podciągnąć pod analizę systemową, której wynikiem będą rekomendacje do zakupu konkretnego rozwiązania. Co do kosztów samego oprogramowania XXXX nie wypowiem się bo po pierwsze nie robię tak szczegółowych badań po drugie koszty licencji i sprzętu we wdrożeniach to ok. 20% całości projektu więc nie są one aż tak istotnym parametrem. Skoro jednak reszta (ludzka praca a wiec kompetencje) stanowi 80% to znaczy, że kompetencje dostawcy się liczą a nie produkt. Od czego więc zależy to czy wybierzemy z cennika oprogramowania za 300zł czy za 300.000 zł??? Myślę, że po analizie ograniczeń każdego z tych rozwiązań wyjdzie odpowiedź na to pytanie... Oprogramowanie z dużymi ograniczeniami wywoła albo ogromną pracochłonność na dostosowanie albo po protu nie obsłuży wielu procesów firmy. Może się jednak zdarzyć, że rozwiązanie za 300zł ma sens i wtedy po protu należy to uczynić. Na koniec moja hipoteza: jeżeli producent wyznaczył jakąś cenę za swoje oprogramowanie to najprawdopodobniej wykonał wiele analiz i cena ta ma uzasadnienie, należy to tylko zrozumieć i uznać. Jeżeli producentem jest firma ogólnoświatowa i w danym sektorze nie jest monopolistą, to jest prawie pewne, że cena ta ma rynkowe uzasadnienie. Prawie...;) Reprezentuje Pan dostawcę oprogramowanie (resellera) wiec pozostaje chyba Pana firmie prowadzić sprzedaż z pozycji doradztwa a nie z pozycji dostawcy oprogramowania. W przeciwnym wypadku jest duże zagrożenie, że klient sam zatrudni doradcę i wtedy stanie się Pan biernym obserwatorem z minimalnym wpływem na własną sprzedaż. Obecnie, moim zdaniem, dostawca oprogramowania albo jest dobrym konsultantem albo ma kłopoty jak każdy dostawca pudełek: walczy ceną. Dla czytelników będących nabywcami: obserwujcie swoich dostawców i oceniajcie ich pracę a nie reklamy produktów. Każdej większej firmie zaś polecam jednak oprogramowanie, które jest szkieletem pozwalającym na stworzenie przyszłego rozwiązania bo nie istnieje coś takiego jak gotowe do wdrożenia oprogramowanie.
Publikacja uzyskana ze strony it-consulting.pl. Autor publikacji jest analitykiem, pracownikiem naukowym i praktykującym ekspertem dziedzinowym z zakresu analizy obiektowej, analizy procesowej, zarządzania i modelowania organizacji, analizy i inżynierii systemów. Specjalizuje się w analizie organizacji, tworzeniu ich modeli informacyjnych i biznesowych oraz projektowaniu i specyfikowaniu systemów informacyjnych, modelowaniu wymagań i ograniczeń na oprogramowanie. Kontakt do autora znajduje się na stronie: it-consulting.pl. |
