Skąd wiedzieć jaki projekt uruchomić?

Oczywiście, aby ochronić marżę na wyrobie (tj. kluczowy miernik, o który troska uniemożliwia pójście za naszą pierwotną intuicją obniżki ceny wyrobów), musimy podjąć jakieś działanie lub jakiegoś działania zaniechać. W naszym przypadku jest to "nie zmieniać cen wyrobów".

W tym momencie konflikt powinien być już oczywisty: aby zapewnić sukces firmy Światło teraz i w przyszłości musimy dbać o wolumen sprzedaży. Aby dbać o wolumen sprzedaży, musimy obniżyć ceny. Ale z drugiej strony, aby zapewnić sukces firmy Światło teraz i w przyszłości, musimy również dbać o marżę. Zaś aby dbać o marżę, musimy utrzymać ceny na dotychczasowym poziomie. A nie da się przecież jednocześnie obniżać cen i utrzymywać ich na tym samym poziomie! Taką sytuację dobrze jest przedstawić na diagramie.

Zobacz również:

  • 9 cech wielkich liderów IT

Sytuacja wydaje się patowa. "Niekiedy możliwym rozwiązaniem podobnego dylematu jest kompromis: obniżamy cenę, ale tylko trochę, by za nie zaszkodzić marży. Jednak w wielu przypadkach jest to już zgniły kompromis" - dodaje Marek Kowalczyk. Jeśli w takim dylemacie nie ma dobrego kompromisu, to mamy dwa wyjścia: albo się poddać i uznać, że nic nie możemy zrobić, albo poszukać fałszywych założeń, które kryją się za poszczególnymi strzałkami logicznymi.

Potęga chmury

"Mam nadzieję, że uważny czytelnik w trakcie lektury poprzedniego akapitu naszpikowanego słowami: muszę i: nie da się, w pewnym momencie poczuł wewnętrzny sprzeciw" - uśmiecha się Marek Kowalczyk. "To odzywa się nasza intuicja menedżerska, gotowa, by pomóc nam rozwiązać problem poprzez podważenie fałszywych założeń" - dodaje. Teraz wystarczy odszukać to słowo "musimy" lub "nie da się", które wzbudza nasz największy wewnętrzny sprzeciw i od niego zacząć analizę założeń. Założenia ujawnia się niewinnym słówkiem "ponieważ", np. aby dbać o wolumen sprzedaży, musimy obniżyć ceny naszych wyrobów, ponieważ:

możemy produkować i sprzedawać tylko takie wyroby, w których dla klienta liczy się wyłącznie cena

nasze obecne produkty możemy oferować jedynie klientom, dla których liczy się tylko cena.

Jeśli zauważymy, że założenia są fałszywe, to problem rozwiązaliśmy - istniał on tylko w naszej głowie i niczym chmura zaciemniał obraz rzeczywistości. Uświadamiając sobie ich fałszywość, właśnie tę chmurę rozwialiśmy! Ale może też być tak, że założenia te są prawdziwe i wtedy warto zastanowić się, co możemy zrobić, by te przestały być prawdziwe lub by ich prawdziwość przestała implikować słowo "musimy". W przypadku firmy Światło oba założenia były fałszywe, co nasunęło przynajmniej dwa możliwe ogólne rozwiązania: opracowanie nowego wyrobu, dla którego cena nie jest najważniejszym kryterium zakupu, i/lub znalezienie takich odbiorców na nasz dotychczasowy produkt, którzy nie są wrażliwi na cenę. "Takie kierunkowe, ogólne rozwiązania nazywamy potocznie: zastrzykami" - dodaje Kowalczyk. Stanowią one pomysły wskazujące nam kierunek dalszych szczegółowych poszukiwań w ramach konkretnych projektów. "Zanim jednak damy się ponieść entuzjazmowi, warto poszukać mniej oczywistych rozwiązań wynikających z podważenia innych strzałek tego diagramu, w tym strzałki oznaczającej konflikt między podnoszeniem a utrzymywaniem cen. Potęga chmury tkwi w zmuszeniu nas do ujawnienia i poddania w wątpliwość naszych najgłębszych założeń o, zdawałoby się, beznadziejnej sytuacji" - zachęca prezes MANDARINE i zauważa, że na tym etapie nie wolno jeszcze poddawać pomysłów krytyce, na co będzie czas później, np. przy wykorzystaniu narzędzia myślowego zwanego "gałęzią negatywną".

Skąd wiedzieć jaki projekt uruchomić?

Dla Czytelników, którzy nadeślą do Redakcji najbardziej oryginalne rozwiązania przedstawionej tu chmury lub chmur własnych, Marek Kowalczyk ufundował kilka egzemplarzy powieści biznesowej "Cel II: To nie przypadek", w której przedstawiona jest m.in. technika chmury. W kolejnym odcinku przedstawimy trzy pytania, które pozwalają błyskawicznie sprawdzić, czy projekt się opłaca i odrzucić błędne hipotezy.

1To, czym różnią się projekty typu 1 od projektów typu 2 było przedmiotem artykułu pt. "Kiedy zabić projekt", który ukazał się w Computerworld nr 7/2010.


TOP 200