Przerażony kameleon - eseje o przyszłości zarządzania - E-mentor
Przerażony kameleon - eseje o przyszłości zarządzania - E-mentor
Przerażony kameleon - eseje o przyszłości zarządzania - E-mentor
- TAGS
- kameleon
- eseje
- e-mentor.edu.pl
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
HoloBox<br />
Zgodnie z przedstawionymi planami, w pierwszej fazie projektu skoncentrujemy się<br />
jednocześnie na dwóch elementach: po pierwsze – na rozwoju HolobBoxu, jego<br />
produkcji oraz zapewnieniu dostępności, po drugie – na rozwoju sieci dostawców<br />
zawartości programów (Content Generatorów). Faza ta będzie trwać do 6 tygodni.<br />
Druga faza obejmie masową dystrybucję HB w różnych wersjach oraz popularyzację<br />
naszego serwera aplikacji. Przewidywany czas trwania tej fazy to następne 20 tygodni.<br />
Trzecia faza, zaczynająca się po 26 tygodniach, to udostępnienie założeń technicznych<br />
HB w GlobNecie – pozwoli to wielu holonom produkcyjnym rozpoczęcie produkcji<br />
urządzeń po bardzo niskich kosztach oraz odbierze naszym konkurentom szansę na<br />
stworzenie klonów HB i sprzedawanie ich z odpowiednią marżą. To doskonały chwyt<br />
obronny w dobie hiperkonkurencji!<br />
W fazie trzeciej nasze zyski będą już w większości pochodzić ze sprzedaży contentu<br />
przez nasz serwer aplikacji. Ten swoisty monopol będzie możliwy dzięki zaimplementowaniu<br />
End Point Interface (EPI) do każdego z HB oraz dla dostawców contentu. EPI<br />
zapewni nam kontrolę nad szyfrowaniem przekazu, a co za tym idzie kontrolę nad<br />
zyskami z serwera aplikacji. Kluczem do sukcesu będzie tutaj uzyskanie masy krytycznej<br />
w przeciągu 2–3 tygodni – nasi konkurenci nie będą w stanie zaatakować naszego<br />
podsegmentu i będziemy czerpali zyski z serwera przez kilkanaście miesięcy, a nawet<br />
może kilka lat.<br />
Jaq: Programy konstrukcyjno-instalacyjne powinniśmy udostępnić w sieci. Myślę, że w obecnej<br />
ekonomii sieciowej ich obsługę przejmą wyspecjalizowani projektanci, jako że nie<br />
każdy będzie potrafił nimi operować, ale to jest zgodne z naszymi założeniami i regułami<br />
sieci. Emitowanie programów otrzymywanych od CG-ów (Content Generators) będzie<br />
związane z odpowiednimi płatnościami dostosowanymi do charakteru użytkowania<br />
– zbudowaniem odpowiedniego modelu zajmie się również firma PP. Przecież serwer<br />
aplikacji będzie naszym głównym źródłem dochodów, obok przychodów ze sprzedaży<br />
naszych wersji stylistycznych HB-ów PRAXIS-a. Powinniśmy zachować niewielką część<br />
udziałów na rynku produktów HB-ów, głównie po to, aby marka była utożsamiana<br />
z naszą firmą. Musimy jednak działać bardzo precyzyjnie. Obok ryzyka finansowego,<br />
choć na podstawie przeprowadzonych analiz nie przewiduję takiej możliwości – zakładając,<br />
że HB będzie pierwszy na rynku, istnieje dodatkowe zagrożenie. Jest nim<br />
włączenie HB do naszego portfela marek, w którym marki są od siebie, chcąc nie<br />
chcąc, w pewien sposób zależne. Błąd czy to produkcyjny, czy rozwojowy, czy też<br />
komunikacyjny dotyczący jednej marki, automatycznie może wpłynąć na postrzeganie<br />
pozostałych marek. Wiem, że bacznie pilnujemy, aby nic takiego nie miało miejsca,<br />
jednak w przypadku HB nasza czujność powinna być na najwyższym poziome. Musimy<br />
wziąć pod uwagę, że HB będzie zupełnie nowym rozwiązaniem technologicznym. Nie<br />
ma jeszcze prototypu, nie ma aplikacji, nie mówiąc o braku mechanizmu działania całej<br />
sieci wspomagającej HB. Dlatego uważam, że powinniśmy przeprowadzić serię wielu<br />
wariantów symulacyjnych przed wprowadzeniem HB na rynek. Pod żadnym pozorem<br />
nie możemy dopuścić do nawet najmniejszej wpadki HB, ponieważ to wpłynęłoby<br />
nie tylko na sam HB, ale na całą PRAXIS, a odbudowa wizerunku firmy jest rzeczą nie<br />
tylko bardzo kosztowną i trudną, ale przede wszystkim czasochłonną, a w dzisiejszych<br />
czasach nie ma miejsca na stratę choćby dnia.<br />
73