[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.
Im bardziej podatne na modyfikacje tym lepiej i bliżej sukcesu.
O sukcesie wdrożenia systemu CRM (nie tylko, dotyczy to każdego oprogramowania wspomagającego zarządzanie) w moich oczach decydują między innymi:
- zrozumienie działalności firmy
- odkrycie prawdziwych procesów biznesowych a nie tylko ścieżek wykonywanej pracy
- właściwe określenie tego co jest procesem, co jest jego wsparciem i co jest jedynie lokalnym zwyczajem do ewentualnej zmiany (optymalizacja)
- to czy narzędzie jest sztywną aplikacją czy rodzajem szkieletu (drugi wariant preferowany)
- to czy szkielet ten implementuje zastosowaną metodą analizy i projektowania procesów (głównie użytą notację)
- to czy szkielet daje możliwość implementacji specyfiki dziedziny danej organizacji (model danych)
1. Nie zawsze jest oczywiste to czym tak na prawdę zajmuje się firma, np. agencja fotograficzna (bank fotografii) nie sprzedaje zdjęć a tylko pośredniczy w zawieraniu umów i zarządza prawami autorskimi.
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 artykuł 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.
