Temat: Jaka metodologia?

Witam,
Jakich metodologii uzywacie przy wdrozeniach systemow CRM?
Po kilku doswiadczeniach z MS CRM sklaniam sie bardziej ku pochodnym agile (+dobra dokumentacja) niz bardziej sztywnym metodologiom.
A co wy o tym sadzicie?

Temat: Jaka metodologia?

Maciej Artur Jankowski:
Witam,
Jakich metodologii uzywacie przy wdrozeniach systemow CRM?
Po kilku doswiadczeniach z MS CRM sklaniam sie bardziej ku pochodnym agile (+dobra dokumentacja) niz bardziej sztywnym metodologiom.
A co wy o tym sadzicie?

sądzę tak samo :) ogólnie, nie tylko dla CRM, warto stosować, etapy:
1. Klient (z ewentualną pomocą analityka z zewnątrz) opisuje co chce osiągnąć (ale nie jak!) (tu w zasadzie stwierdzenie: obniżenie kosztów o 1 mln zł w ciągu roku stanowi niejako budżet projektu i okres zwrotu bo to nic innego jak ROI)
2. W toku analizy biznesowej powstaje odpowiedź na pytanie Jak to osiągnąć.
3. Po uzyskaniu zgody Klienta powstaje specyfikacja wymagań na oprogramowanie (jakąś tam metodyką..., każdy ma swoją)
4. na tej podstawie dostawca gotowego, parametryzowanego oprogramowania tworzy dokument opisujący co należny zrobić by zbliżyć się wymagań zamawiającego i powstaje lista co jest w systemie, co można zrobić metoda poprawek i czego nie da się tak zrobić i należy napisać "od zera". - wycena pracy.
5. Konfrontacja tego z budżetem to ocena wykonywalności projektu.

...
:)

Temat: Jaka metodologia?

Jarek Ż.:

etapy:
1. Klient (z ewentualną pomocą analityka z zewnątrz) opisuje co chce osiągnąć (ale nie jak!)

Dlaczego "nie jak" ?

4. na tej podstawie dostawca gotowego, parametryzowanego oprogramowania tworzy dokument opisujący co należny zrobić

Dlaczego gotowego :) ?

Temat: Jaka metodologia?

Moze ja sie nie znam, ale:

* Moim zdaniem, jesli decydujesz sie na wybor partnera do jakiegokolwiek wdrozenia to z reguly znaczy, ze nie masz tyle doswiadczenia, wiec - o ile Twoja opinia jest zawsze mile widziana, pamietaj, ze rozmawiasz (powinienes rozmawiac) z ludzmi, ktorzy zyja z tego co robia i powinni "wiedziec lepiej" jak poprowadzic projekt.

* Dlatego gotowego, bo z reguly wiaze sie to ze znacznie nizszym ryzykiem (wielu czynnikow).

Jakie sa Twoje argumenty?

Temat: Jaka metodologia?

Grzegorz Koronowski:

Jarek Ż.:

etapy:
1. Klient (z ewentualną pomocą analityka z zewnątrz) opisuje co chce osiągnąć (ale nie jak!)

Dlaczego "nie jak" ?

Naturalny cykl projektowy to:
- co chce zrobić
- jak to zrobić

na pierwsze pytanie tu odpowiada manager (biznes) na drugie inżynier. Jak idę do krawca to mówię, że chce garnitur na wesele ale już nie mówię mu jak ma go uszyć, zamawiam wygląd i jakość.

Zwracam uwagę, że "co zrobić" i "jak zrobić" to naturalne etapy rozwiązywania problemów inżynierskich i analizy systemowej.

Nie wyobrażam sobie jak rozwiązać problem wzrostu sprzedaży zaczynając od pisania jakiegokolwiek kodu, pytanie pracowników co im pomoże jest bez sensu bo skończy się co najwyżej udoskonaleniem obecnego narzędzia lub czegoś innego "fajniejszego" a wzrost sprzedaży może wymagać np. zmiany organizacji pracy a potem dopiero implementacji nowych potrzebnych funkcji, których metodą "od razu rzucamy się na programowanie" nigdy się nie rozwiąże.

Po określeniu funkcjonalności jest miejsce na opis tego jak ją osiągnąć...

4. na tej podstawie dostawca gotowego, parametryzowanego oprogramowania tworzy dokument opisujący co należny zrobić

Dlaczego gotowego :) ?

Bo na dzisiaj pisanie czegoś dla biznesu "od zera" jest dla mnie stratą czasu i dużym kosztem. Są gotowe systemy i szkielety (zręby, frameworki) itp. problem oprogramowania biznesowego polega na wykonaniu analizy tego jakie informacje i jak są przetwarzane w firmie (model danych i model procesów), do tego dochodzi, to które czynności i jak wspomóc a na koniec określić czy i jakie dane są (powinny być) wymieniane z innymi systemami.

Aby to zrobić nie ma sensu na dzisiaj pisać od zera kodu a warto wybrać jakiś szkielet zależnie od klasy problemu do rozwiązania. Pisanie od zera to raczej tworzenie specyficznych dla problemu pojedynczych elementów (interfejs, sterownik, itp.).

Na dzisiaj np. pisanie systemu obiegu dokumentów to w moich oczach niekompetencja bo obieg dokumentów można rozwiązać dostępnymi na rynku szkieletami typu, SharePoint, WebSpheare, flow cokolwiek bądź itp. ... dotyczy to oczywiście nietrywialnych potrzeb. Trywialne rozwiązuje się za trywialne pieniądze, nie widzę tu miejsca na kosztowną prace programistów bo trywialny problem wymaga drogiej pracy od zera więc jest nierentowny, nietrywialny problem wygeneruje megaprojekt a po wymyślać koło?

Oczywiście nie dopuszczam myśli, że oferuje się klientowi pisanie programu tylko dlatego że to droga usługa i "zarobimy kasę" bo to nieetyczne i amatorskie praktyki ...

Temat: Jaka metodologia?

Jarek Ż.:

Grzegorz Koronowski:

Jarek Ż.:

etapy:
1. Klient (z ewentualną pomocą analityka z zewnątrz) opisuje co chce osiągnąć (ale nie jak!)

Dlaczego "nie jak" ?

Naturalny cykl projektowy to:
- co chce zrobić
- jak to zrobić

Bardzo by mi się to podobało. Tak postawiona sprawa stawia konkretne i jasne fundamenty uprawnień i odpowiedzialności pod dalszą, nawet burzliwą współpracę na linii Klient - Dostawca.
Ale, hmmm... Panowie oczywiście nieco upraszczacie,
zapewne w celach edukacyjnych.

Odpowiedź na pytanie co chce zrobić (osiągnąć) Klient w kategoriach kryteriów biznesowych w pierwszym kroku będzie dość ogólna.

Na tej podstawie odpowiedź dostawcy siłą rzeczy będzie podobnie nieszczegółowa.
(no chyba, że to będzie odpowiedź spryciarza-pozyskiwacza podpisów: "A, Państwo chcecie sprzedaż zwiększyć o X w czasie T? A to proszę bardzo, mamy taki CRM gotowy dla firm takich jak Państwa, który jak się go dobrze używa, to zwiększa o 2 razy X za X przez 4, ROI piękne, wiemy jak, tu referencje, to co stoi na przeszkodzie złożyć podpis pod umową tu teraz?"). ;-)

Po ogólnej odpowiedzi, zapewne wariantowej i uwarunkowanej, dialog między stronami musi w rzeczywistości chyba trochę potrwać, trochę problemów i zależności przyczynowo-skutkowych w obecnym działaniu Klienta trzebaby zrozumieć Dostawco, trochę sugestii doradczych wynikających z twojego dośiadczenia projektowego wartoby Klientowi pokazać i trochę dokumentacji powinno to podsumować tak,
aby rzeczywiście można było postawić tę granicę, po której Klient mówi Ci: - tak, jak to spełni wasz końcowy produkt, to wszystko mi jedno jak to zrobicie.

I mnie też ciekawią praktyczne doświadczenia metodyczne zmierzające do takiej sytuacji. Jak to robicie?

Idąc samemu także drogą uproszczeń, to przenieśmy akcent też w drugą stronę - niech Klient nie mówi Dostawcom nawet co (nie tylko jak) zrobić. Nieprofesjonalne? Ale my nie dyskutujemy o beznadziejnych przypadkach? Zostawić go spryciarzom lub pudełkom? Klient musi wiedzieć czego chce? Co wtedy?
Na przykład taki dialodżek:
Sponsor: - przymierzamy się do wdrożenia CRMa bo ... ,
Dostawca: - a co byłoby najważniejszym celem takiego projektu?
Sponsor: - to pan jest chyba ekspertem, więc niech pan mnie nie pyta tylko mi powie co powinno być celem takiego projektu?

I tu pojawia się seria pytań samo-określające dostawcę:
- czy my jesteśmy od konsultacji biznesowych czy od wdrożenia CRMów?
- czy konsekwentnie trzymać się ... (w miejsce trzech kropek wstaw własny światopogląd w tej sprawie, np.: metodyki / dobrych praktyk prowadzenia projektów CRM / strategii naszej firmy / kompetencji które mamy itp) i iść z dumnie podniesioną głową gdzie indziej?
A może sugerować i podpowiadać (no na przykład firma taka to a taka za cel postawiła sobie to i to)?

Bardzo ciekaw jestem, czy uważacie takie dylematy za ważne i prawdziwe, czy może właśnie za pytania pozorne i źle postawione?

Temat: Jaka metodologia?

No toś Pan Panie Marcinie nieźle zaszpuntował ten wątek - na całe pół roku!
Widać, że pytania były tendencyjne i o rzeczy nader wstydliwe :)))

Od pewnego czasu analizuję wypowiedzi w Grupie CRM i doprowadziło mnie to do następującego ciągu myślowego:

1. Suma poruszanych problemów i prezentowanych poglądów skrzyżowana z przekrojem profesji i specjalizacji ich autorów odzwierciedla stan i obraz tych spraw w naszej firmowej rzeczywistości.

2. Ów stan i obraz rzeczywistości podsumowany został niedawno w opublikowanym przez K2Consulting raporcie Największe ryzyka wdrożeń CRM.

3. Autorów wypowiedzi w Grupie CRM odbieram następująco:

a) większość to informatycy i wdrożeniowcy ze strony Dostawców. Najczęściej wypowiadają się o swoich pudełkach.

b) kolejna grupa to informatycy ze strony Klientów.
Najczęściej wypowiadają się o nazwach pudełek, o różnicach między nimi i składają relacje z pomyślnych wdrożeń CRM-ów w swoich firmach (tzn. z pomyślnych zainstalowań zakupionych pudełek).

c) przedostatnia, już bardzo nieliczna grupa, to biznesowcy ze strony Klientów.
Zazwyczaj zadają sakramentalne pytanie - "Jaki jest najlepszy CRM dla mojej firmy?"

d) ostatnia grupa, liczona nieledwie na palcach, to niezależni wdrożeniowcy i konsultanci z wieloletnim doświadczeniem.
Właśnie oni poruszają takie wstydliwe rzeczy jak: strategia, cel biznesowy, zarządzanie zmianą, kompetencje, ROI, dobre praktyki prowadzenia projektów ...

4. Tak się dziwnie składa, że ignorowanie tych wstydliwych rzeczy zostało zidentyfikowane ww wspomnianym Raporcie jako największe ryzyka wdrożeń CRM.

5. Mamy zatem z jednej strony Dostawców konkurujących swoimi pudełkami a z drugiej strony Klientów:
a) bezbronnych wobec siły przekazu salesmanów Dostawców,
b) bezbronnych wobec informatyków i wdrożeniowców Dostawców,
c) bezbronnych wobec własnych informatyków.

6. Szczęśliwi ci Klienci, którzy mają na swoim pokładzie odpowiednie kompetencje do profesjonalnego wdrożenia: od sformułowania strategii, celu i wymagań, poprzez wybór i implementację rozwiązania, na pełnym przeprowadzeniu firmy przez calą zmianę kończąc!

7. Jaka rada dla pozostałych Klientów?
Zastąpić schemat Dostawca->Klient schematem Dostawca->Niezależny Profesjonalny Konsultant->Klient.
Konsultant jest wynajęty przez Klienta i pracuje na jego rzecz.
Niezależność Konsultanta to merytoryczny wybór rozwiązania.
Profesjonalizm Konsultanta to sukces wdrożenia.

Pozdrawiam

Maciej Sztompke

Temat: Jaka metodologia?

Panie Macieju, nic dodać nic ująć do Pana diagnozy i syntezy tematu.

Bardzo dziękuję za odkorkowanie tematu - faktycznie już było mi trochę wstyd ;-)

Temat: Jaka metodologia?

Panie Macieju- bardzo ciekawa opinia i dużo w niej prawdy.
Z mojego punktu widzenia - jako konsultanta- sprzedawcy CRM dla tzw. miśków- widzę także brak operowania na celach biznesowych, korzyściach i planowaniu długoterminowym wśród klientów i podczas rozmów z nimi. Co poniekąd faktycznie wiąże się z kiepskim zrozumieniem idei i potencjału CRM.

Bardzo często nie operuje się językiem korzyści głównie dlatego, że na wybór systemu i dostawcy wpływają 2 czynniki: cena oraz opinia specjalisty- zaufanego/własnego informatyka. Sprowadza się to do tego, że siłą rzeczy dyskusja nie toczy się o potencjale biznesowych, ale o używanej bazie danych i innych zagadnieniach informatycznych. itp Nie ma się w sumie czemu dziwić- każdy mówi o tym w czym czuje się najpewniej. Korzyści są jak najbardziej uzasadnione gdy druga strona w ramach grupy decyzyjnej przedstawia brutalnie mówiąc - osoby kompetentne do tego nie tylko uprawnieniami ale też pewna wiedzą i świadomością.

Druga sprawa, że często punktem wyjścia faktycznie są cele, natomiast potem temat się szybko rozdrabnia, i albo wybiera się firmę z racji na rekomendacje albo " bo zrobi wszystko za x zł". Ten drugi przykład boli mnie zwłaszcza, bo jest to ewidentne wprowadzanie Klientów w błąd aby pozyskać umowę...

Każdy dobry projekt powinien zacząć się od analizy przedwdrożeniowej właśnie w kontekście celów. Dyskutowałbym kto to powinien robić - czy osoba niezależna, czy doradca dostawcy- prawda jest taka że każda wersja ma plusy i minusy.
Dobra analiza powinna zawierać nie tylko cele projektu które klient zna już teraz, ale warto pokusić się o dokładne poznanie firmy i procesów wewn. Wtedy bowiem konsultanci, o ile są nieźli, mogą zabłysnąć podsuwając inne rozwiązania pewnych utartych schematów, nierzadko natury stricte organizacyjnej. Od klienta zależy czy nowy model działania mu pasuje – nic na siłę.

Podejście, w którym to wdrożeniowcy mają wskazać cele - osobiście uważam, że jest to ciężkie do ... sprzedaży :) Prawda jest taka, że aby podjąć decyzję o wdrożeniu systemu- czy CRM czy innego klient wydając kasę w 99% chce wiedzieć na co to wyda, lub dokładniej - co dzięki temu zyska. Jeżeli firmy nie znamy, nie wiemy jak pracują ludzie, kto jest ich obecnymi klientami, których klientów utracili i dlaczego itd to nastąpić musi seria bardzo wielu pytań, która aby miała jakieś ręce i nogi w ujęciu merytorycznym musi sprowadzić się do ... analizy przedwdrożeniowej. W innym przypadku stawianie celów będzie jak wróżenie z fusów. Bo żeby coś fajnego osiągnąć to trzeba poznać potencjał klienta – jego mocne i słabe strony. Co oczywiście nie zmienia faktu, że warto podpowiadać, gdy coś klient może zrobić inaczej- lepiej. W końcu jego sukces przełoży się też na nasz 

Temat: Jaka metodologia?

A według mnie nie można stwierdzić "CRM wdrażamy za pomocą Agile'a" albo "CRM wdrażamy za pomocą metodyk formalnych (PMI/Prince itp.)". Wszystko zależy od konkretnego projektu, stopnia jego przygotowania i (jeśli nie przede wszystkim) stopnia świadomości Klienta.
Według mnie metodyki prowadzenia projektu nie wybieramy w zależności od rodzaju softu, jaki wdrażamy.
Generalnie wyznawaną przeze mnie przynajmniej zasadą jest:
1. Jeśli Klient ma dobrze sprecyzowane wymagania, wie czego chce, dokładnie ma przeanalizowane (lub jest gotowy, aby to zrobić) procesy - wybieramy metodykę formalną. Możemy bowiem określić dokładny scope projektu, specyfikację wymagań na dużym poziomie szczegółowości i możemy zakładać, że soft wykonany zgodnie z tymi specyfikacjami (również funkcjonalną) będzie zgodny z wymaganiami. Niebagatelną rolę gra tutaj również fakt posiadania przez Klienta świadomych ludzi w IT - którzy będą rozumieli system nie tylko od strony biznesowej, ale również technicznej (w szczególności którzy będą potrafili zrozumieć, jak aspekty techniczne wpłyną na core business firmy, w której pracują)
2. Jeśli Klient nie wie w ogóle, albo nie do końca wie, czego chce (chcemy wdrożyć CRMa... i to wszystko :) ) - wtedy metodyki swobodne (Agile) będą zdecydowanie lepszym pomysłem, aniżeli PMI/Prince/pochodne (jakieś ASAPy itp.). Cały projekt bowiem wspiera w bardzo dużym stopniu proces zarządzania zmianą - która w takich wdrożeniach stanowi niejako sedno. Ponadto specyfikację końcowego rozwiązania tak naprawdę "tworzymy na bieżąco" (jeden z moich klientów uwielbia określenie "rozpoznania bojem" :) ).

Oczywiście, istnieje możliwość niejako powiązania tych metodyk - robiąc prototyp / proof of concept rozwiązania metodyką Agile, a później rozpisując projekt rozwiązania finalnego metodyką formalną. Rozwiązanie to posiada zdecydowany plus - dostajemy nie tylko rozwiązanie dopasowane do naszych potrzeb, ale również optymalnie zrobione i przygotowane. Minusem jest jednak budżet - dość wysoki z uwagi na de facto 2 projekty :) Bo najczęstszym (a jednocześnie jednym z najpoważniejszych) błędem, jaki się popełnia, to że robimy prototyp, a później stwierdzamy, że OK - zostawiamy prototyp na produkcji (bo fajnie działa - szkoda, że tylko w środowisku testowym :) ). I zaczynają się problemy - wydajnościowe, bugfix kodu napisanego "na szybko" (w końcu prototypowego) itp.

Podsumowując więc - jednoznaczne określenie metodyki wdrożeń CRM nie jest możliwe - bo projekt projektowi nierówny.
Według mnie można to jednak podzielić w pewnym stopniu na bazie statystyki:
1. Projekty w MSP - głównie Agile
2. Projekty w LE - metodyki formalne lub podejście wiązane (prototyp Agile, produkcja formalna)