HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

A szeptember 22-i, 8. PM műhely témája a projekt kommunikáció volt.

Most nem magáról a rendezvényről írok, mert annak a jegyzőkönyve elérhető lesz. Sokkal inkább a kommunikációról írnék bővebben. Mint a helyszínen kiderült, ez egy túlságosan tág téma (elvégre mindenki kommunikál mindenkivel), túl sok a lehetőség a bullshit-jellegű aranyköpésekre, és túl könnyű eltérni a témától (mindenkinek van egy vicces sztorija).

Tehát maradjunk a témánál: projekt kommunikáció.

Először a fogalmakat tisztázzuk, nehogy letérjünk az útról. Szerintem a média kommunikáció nem tartozik ide, ilyen például amikor a 4-es metró projektről írnak az újságban. Ugyanígy nem tartozik ide a kávéautomata melletti informális beszélgetés, még akkor se, ha a projekttel kapcsolatos kulcsfontosságú információáramlás történik.

Amit a projekt kommunikáció alatt értek, az mindazon kommunikáció, illetve kommunikációs csatorna, ami minimálisan szükséges a projekt sikeréhez. Tehát amikor tervezetten, irányítottan és tudatosan a projekt (a projektvezető) információt átad vagy megoszt.

A projekt sikeréhez szükség van a megfelelő kommunikációs csatornák kiépítésére (pl. projektvezető – projekt szponzor), ezek összessége a Project Communication Plan. Ugyanis a kommunikációs tervet előre kell elkészíteni, a projekt indulásakor.

Megjegyzem, hogy a projekt indítása előtt is létezik munka, ennek a munkának pedig megvan a maga kommunikációja. De ezzel most nem foglalkoznék.

Ki a felelős a kommunikációért? Alapesetben a projektvezető, hiszen az ő feladat a projekt teljesítése, és a kommunikáció ehhez csak egy eszköz. A kommunikáció és az információ-forgalmazás tipikusan menedzseri feladat. Természetesen lehetséges, hogy a projektvezető bizonyos kommunikációs feladatokat másokra biz, például a projekt asszisztens írja a meeting minutes-t és küldi ki az érdekelteknek.

Miről szól a kommunikáció terv?

- Milyen típusú információt

- Kinek

- Milyen rendszerességgel

- Kik szolgáltatják az információt

- Hogyan

- Mi a célunk a kommunikációval

Példa: http://pasztor.freeblog.hu/files/Projekt%20kommunikáció.pdf

A legtöbb esetben a formátum standard vagy kötött, tehát létezik egy minta amit fel kell tölteni tartalommal. A trükk az, hogy ezeket a mintákat ismerjük, illetve azt felismerjük, hogy melyikre van szükségünk és melyikre nincs.

Mikor jó a kommunikáció? Erről nagy vita volt a rendezvényen, ezért saját definíciót használnék: akkor jó a kommunikáció, ha mindenki rendelkezik a munkavégzéshez szükséges információval. Például a fejlesztő tudja azt, hogy mik a felhasználók igényei, illetve a szponzor tisztában van a projekt aktuális állásával.

Honnan lehet tudni, hogy kinek milyen információra lesz szüksége? Ez adódik a projekt felépítéséből, az alkalmazott módszertanból és a korábbi tapasztalatból. Legrosszabb esetben kérdezni is lehet.

A jó kommunikáció annak a felelőssége, aki kommunikál. Figyelembe kell venni, hogy a „kommunikációs csatorna” zajos, és hogy a kommunikáció része a kódolás-dekódolás folyamat. Előfordulhat, hogy a hallgatóság másképp dekódolja az üzenetet, mint ahogyan a beszélő szerette volna – ezért figyelni kell az egyértelmű és tiszta üzenetekre, illetve fontos a hallgatóság visszajelzése.

Mennyire fontos az informális kommunikáció? Biztosan mindenkinek van egy vicces története arról, amikor a hivatalos út helyett valamit „szoft” módon, informális kommunikációval oldott meg. Az informális kommunikáció is fontos, néha csak ilyen úton lehet eljutni a sikerig, ennek ellenére én nem nevezném projekt kommunikációnak. Ugyanis az informális kommunikáció szerepe nem más, mint helyettesíteni vagy erősíteni a formálisat.

Hogyan lehet jól kommunikálni?

Mint ahogyan a PM műhelyhez kapcsolódó blogon olvashatjuk, a kommunikáció rendszerint akkor válik kritikus elemmé, amikor rossz – tehát utólag amikor egy projekt megbukik, akkor mondjuk azt, hogy a kudarc oka a rossz/gyenge kommunikáció volt.

Amikor a projekt megbukik, akkor már késő, ezért proaktívan, a projekt indulási fázisban (vagy még hamarabb) kell elkezdeni jól kommunikálni. Ehhez olyan menedzserekre van szükség, akik értenek hozzá. A kommunikációt meg lehet tanulni, jó lenne ha az egyetemen része lenne a tantervnek, de akár már középiskolában el lehet kezdeni. Kommunikációra szerintem minden embernek szüksége van, még a kockafejű informatikusoknak is. A menedzsereknek pedig „munkaköri kötelesség”.

Amikor egy menedzsert – különösen ha projekt menedzsert – vesznek fel, akkor a szakmai képességeken felül a kommunikációs képességeket is fel kell mérni. Na nem arra gondolok, hogy tud-e megnyerően beszélni a jelölt, hanem hogy ismeri-e a különböző kommunikációs csatornákat, és ezeket tudatosan, a helyzettől függően használja-e.

Aki nincs tisztában a kommunikációs modellel és a kommunikációs eszközökkel, az menjen el tanfolyamra. Sokat nyer vele.

Ps. Egyébként a kommunikációról itt már sokszor volt szó, például Jó koordinálás és jó kommunikáció – nem ugyanaz, A hatásos kommunikáció vagy Hogyan kommunikálj az IT-n belül?

A szeptember 22-i, 8. PM műhely témája a projekt kommunikáció volt.

Most nem magáról a rendezvényről írok, mert annak a jegyzőkönyve elérhető lesz. Sokkal inkább a kommunikációról írnék bővebben. Mint a helyszínen kiderült, ez egy túlságosan tág téma (elvégre mindenki kommunikál mindenkivel), túl sok a lehetőség a bullshit-jellegű aranyköpésekre, és túl könnyű eltérni a témától (mindenkinek van egy vicces sztorija).

Tehát maradjunk a témánál: projekt kommunikáció.

Először a fogalmakat tisztázzuk, nehogy letérjünk az útról. Szerintem a média kommunikáció nem tartozik ide, ilyen például amikor a 4-es metró projektről írnak az újságban. Ugyanígy nem tartozik ide a kávéautomata melletti informális beszélgetés, még akkor se, ha a projekttel kapcsolatos kulcsfontosságú információáramlás történik.

Amit a projekt kommunikáció alatt értek, az mindazon kommunikáció, illetve kommunikációs csatorna, ami minimálisan szükséges a projekt sikeréhez. Tehát amikor tervezetten, irányítottan és tudatosan a projekt (a projektvezető) információt átad vagy megoszt.

A projekt sikeréhez szükség van a megfelelő kommunikációs csatornák kiépítésére (pl. projektvezető – projekt szponzor), ezek összessége a Project Communication Plan. Ugyanis a kommunikációs tervet előre kell elkészíteni, a projekt indulásakor.

Megjegyzem, hogy a projekt indítása előtt is létezik munka, ennek a munkának pedig megvan a maga kommunikációja. De ezzel most nem foglalkoznék.

Ki a felelős a kommunikációért? Alapesetben a projektvezető, hiszen az ő feladat a projekt teljesítése, és a kommunikáció ehhez csak egy eszköz. A kommunikáció és az információ-forgalmazás tipikusan menedzseri feladat. Természetesen lehetséges, hogy a projektvezető bizonyos kommunikációs feladatokat másokra biz, például a projekt asszisztens írja a meeting minutes-t és küldi ki az érdekelteknek.

Miről szól a kommunikáció terv?

- Milyen típusú információt

- Kinek

- Milyen rendszerességgel

- Kik szolgáltatják az információt

- Hogyan

- Mi a célunk a kommunikációval

Példa: http://pasztor.freeblog.hu/files/Projekt%20kommunikáció.pdf

A legtöbb esetben a formátum standard vagy kötött, tehát létezik egy minta amit fel kell tölteni tartalommal. A trükk az, hogy ezeket a mintákat ismerjük, illetve azt felismerjük, hogy melyikre van szükségünk és melyikre nincs.

Mikor jó a kommunikáció? Erről nagy vita volt a rendezvényen, ezért saját definíciót használnék: akkor jó a kommunikáció, ha mindenki rendelkezik a munkavégzéshez szükséges információval. Például a fejlesztő tudja azt, hogy mik a felhasználók igényei, illetve a szponzor tisztában van a projekt aktuális állásával.

Honnan lehet tudni, hogy kinek milyen információra lesz szüksége? Ez adódik a projekt felépítéséből, az alkalmazott módszertanból és a korábbi tapasztalatból. Legrosszabb esetben kérdezni is lehet.

A jó kommunikáció annak a felelőssége, aki kommunikál. Figyelembe kell venni, hogy a „kommunikációs csatorna” zajos, és hogy a kommunikáció része a kódolás-dekódolás folyamat. Előfordulhat, hogy a hallgatóság másképp dekódolja az üzenetet, mint ahogyan a beszélő szerette volna – ezért figyelni kell az egyértelmű és tiszta üzenetekre, illetve fontos a hallgatóság visszajelzése.

Mennyire fontos az informális kommunikáció? Biztosan mindenkinek van egy vicces története arról, amikor a hivatalos út helyett valamit „szoft” módon, informális kommunikációval oldott meg. Az informális kommunikáció is fontos, néha csak ilyen úton lehet eljutni a sikerig, ennek ellenére én nem nevezném projekt kommunikációnak. Ugyanis az informális kommunikáció szerepe nem más, mint helyettesíteni vagy erősíteni a formálisat.

Hogyan lehet jól kommunikálni?

Mint ahogyan a PM műhelyhez kapcsolódó blogon olvashatjuk, a kommunikáció rendszerint akkor válik kritikus elemmé, amikor rossz – tehát utólag amikor egy projekt megbukik, akkor mondjuk azt, hogy a kudarc oka a rossz/gyenge kommunikáció volt.

Amikor a projekt megbukik, akkor már késő, ezért proaktívan, a projekt indulási fázisban (vagy még hamarabb) kell elkezdeni jól kommunikálni. Ehhez olyan menedzserekre van szükség, akik értenek hozzá. A kommunikációt meg lehet tanulni, jó lenne ha az egyetemen része lenne a tantervnek, de akár már középiskolában el lehet kezdeni. Kommunikációra szerintem minden embernek szüksége van, még a kockafejű informatikusoknak is. A menedzsereknek pedig „munkaköri kötelesség”.

Amikor egy menedzsert – különösen ha projekt menedzsert – vesznek fel, akkor a szakmai képességeken felül a kommunikációs képességeket is fel kell mérni. Na nem arra gondolok, hogy tud-e megnyerően beszélni a jelölt, hanem hogy ismeri-e a különböző kommunikációs csatornákat, és ezeket tudatosan, a helyzettől függően használja-e.

Aki nincs tisztában a kommunikációs modellel és a kommunikációs eszközökkel, az menjen el tanfolyamra. Sokat nyer vele.

Ps. Egyébként a kommunikációról itt már sokszor volt szó, például Jó koordinálás és jó kommunikáció – nem ugyanaz, A hatásos kommunikáció vagy Hogyan kommunikálj az IT-n belül?

A szeptember 22-i, 8. PM műhely témája a projekt kommunikáció volt.

Most nem magáról a rendezvényről írok, mert annak a jegyzőkönyve elérhető lesz. Sokkal inkább a kommunikációról írnék bővebben. Mint a helyszínen kiderült, ez egy túlságosan tág téma (elvégre mindenki kommunikál mindenkivel), túl sok a lehetőség a bullshit-jellegű aranyköpésekre, és túl könnyű eltérni a témától (mindenkinek van egy vicces sztorija).

Tehát maradjunk a témánál: projekt kommunikáció.

Először a fogalmakat tisztázzuk, nehogy letérjünk az útról. Szerintem a média kommunikáció nem tartozik ide, ilyen például amikor a 4-es metró projektről írnak az újságban. Ugyanígy nem tartozik ide a kávéautomata melletti informális beszélgetés, még akkor se, ha a projekttel kapcsolatos kulcsfontosságú információáramlás történik.

Amit a projekt kommunikáció alatt értek, az mindazon kommunikáció, illetve kommunikációs csatorna, ami minimálisan szükséges a projekt sikeréhez. Tehát amikor tervezetten, irányítottan és tudatosan a projekt (a projektvezető) információt átad vagy megoszt.

A projekt sikeréhez szükség van a megfelelő kommunikációs csatornák kiépítésére (pl. projektvezető – projekt szponzor), ezek összessége a Project Communication Plan. Ugyanis a kommunikációs tervet előre kell elkészíteni, a projekt indulásakor.

Megjegyzem, hogy a projekt indítása előtt is létezik munka, ennek a munkának pedig megvan a maga kommunikációja. De ezzel most nem foglalkoznék.

Ki a felelős a kommunikációért? Alapesetben a projektvezető, hiszen az ő feladat a projekt teljesítése, és a kommunikáció ehhez csak egy eszköz. A kommunikáció és az információ-forgalmazás tipikusan menedzseri feladat. Természetesen lehetséges, hogy a projektvezető bizonyos kommunikációs feladatokat másokra biz, például a projekt asszisztens írja a meeting minutes-t és küldi ki az érdekelteknek.

Miről szól a kommunikáció terv?

- Milyen típusú információt

- Kinek

- Milyen rendszerességgel

- Kik szolgáltatják az információt

- Hogyan

- Mi a célunk a kommunikációval

Példa: http://pasztor.freeblog.hu/files/Projekt%20kommunikáció.pdf

A legtöbb esetben a formátum standard vagy kötött, tehát létezik egy minta amit fel kell tölteni tartalommal. A trükk az, hogy ezeket a mintákat ismerjük, illetve azt felismerjük, hogy melyikre van szükségünk és melyikre nincs.

Mikor jó a kommunikáció? Erről nagy vita volt a rendezvényen, ezért saját definíciót használnék: akkor jó a kommunikáció, ha mindenki rendelkezik a munkavégzéshez szükséges információval. Például a fejlesztő tudja azt, hogy mik a felhasználók igényei, illetve a szponzor tisztában van a projekt aktuális állásával.

Honnan lehet tudni, hogy kinek milyen információra lesz szüksége? Ez adódik a projekt felépítéséből, az alkalmazott módszertanból és a korábbi tapasztalatból. Legrosszabb esetben kérdezni is lehet.

A jó kommunikáció annak a felelőssége, aki kommunikál. Figyelembe kell venni, hogy a „kommunikációs csatorna” zajos, és hogy a kommunikáció része a kódolás-dekódolás folyamat. Előfordulhat, hogy a hallgatóság másképp dekódolja az üzenetet, mint ahogyan a beszélő szerette volna – ezért figyelni kell az egyértelmű és tiszta üzenetekre, illetve fontos a hallgatóság visszajelzése.

Mennyire fontos az informális kommunikáció? Biztosan mindenkinek van egy vicces története arról, amikor a hivatalos út helyett valamit „szoft” módon, informális kommunikációval oldott meg. Az informális kommunikáció is fontos, néha csak ilyen úton lehet eljutni a sikerig, ennek ellenére én nem nevezném projekt kommunikációnak. Ugyanis az informális kommunikáció szerepe nem más, mint helyettesíteni vagy erősíteni a formálisat.

Hogyan lehet jól kommunikálni?

Mint ahogyan a PM műhelyhez kapcsolódó blogon olvashatjuk, a kommunikáció rendszerint akkor válik kritikus elemmé, amikor rossz – tehát utólag amikor egy projekt megbukik, akkor mondjuk azt, hogy a kudarc oka a rossz/gyenge kommunikáció volt.

Amikor a projekt megbukik, akkor már késő, ezért proaktívan, a projekt indulási fázisban (vagy még hamarabb) kell elkezdeni jól kommunikálni. Ehhez olyan menedzserekre van szükség, akik értenek hozzá. A kommunikációt meg lehet tanulni, jó lenne ha az egyetemen része lenne a tantervnek, de akár már középiskolában el lehet kezdeni. Kommunikációra szerintem minden embernek szüksége van, még a kockafejű informatikusoknak is. A menedzsereknek pedig „munkaköri kötelesség”.

Amikor egy menedzsert – különösen ha projekt menedzsert – vesznek fel, akkor a szakmai képességeken felül a kommunikációs képességeket is fel kell mérni. Na nem arra gondolok, hogy tud-e megnyerően beszélni a jelölt, hanem hogy ismeri-e a különböző kommunikációs csatornákat, és ezeket tudatosan, a helyzettől függően használja-e.

Aki nincs tisztában a kommunikációs modellel és a kommunikációs eszközökkel, az menjen el tanfolyamra. Sokat nyer vele.

Ps. Egyébként a kommunikációról itt már sokszor volt szó, például Jó koordinálás és jó kommunikáció – nem ugyanaz, A hatásos kommunikáció vagy Hogyan kommunikálj az IT-n belül?

A szeptember 22-i, 8. PM műhely témája a projekt kommunikáció volt.

Most nem magáról a rendezvényről írok, mert annak a jegyzőkönyve elérhető lesz. Sokkal inkább a kommunikációról írnék bővebben. Mint a helyszínen kiderült, ez egy túlságosan tág téma (elvégre mindenki kommunikál mindenkivel), túl sok a lehetőség a bullshit-jellegű aranyköpésekre, és túl könnyű eltérni a témától (mindenkinek van egy vicces sztorija).

Tehát maradjunk a témánál: projekt kommunikáció.

Először a fogalmakat tisztázzuk, nehogy letérjünk az útról. Szerintem a média kommunikáció nem tartozik ide, ilyen például amikor a 4-es metró projektről írnak az újságban. Ugyanígy nem tartozik ide a kávéautomata melletti informális beszélgetés, még akkor se, ha a projekttel kapcsolatos kulcsfontosságú információáramlás történik.

Amit a projekt kommunikáció alatt értek, az mindazon kommunikáció, illetve kommunikációs csatorna, ami minimálisan szükséges a projekt sikeréhez. Tehát amikor tervezetten, irányítottan és tudatosan a projekt (a projektvezető) információt átad vagy megoszt.

A projekt sikeréhez szükség van a megfelelő kommunikációs csatornák kiépítésére (pl. projektvezető – projekt szponzor), ezek összessége a Project Communication Plan. Ugyanis a kommunikációs tervet előre kell elkészíteni, a projekt indulásakor.

Megjegyzem, hogy a projekt indítása előtt is létezik munka, ennek a munkának pedig megvan a maga kommunikációja. De ezzel most nem foglalkoznék.

Ki a felelős a kommunikációért? Alapesetben a projektvezető, hiszen az ő feladat a projekt teljesítése, és a kommunikáció ehhez csak egy eszköz. A kommunikáció és az információ-forgalmazás tipikusan menedzseri feladat. Természetesen lehetséges, hogy a projektvezető bizonyos kommunikációs feladatokat másokra biz, például a projekt asszisztens írja a meeting minutes-t és küldi ki az érdekelteknek.

Miről szól a kommunikáció terv?

- Milyen típusú információt

- Kinek

- Milyen rendszerességgel

- Kik szolgáltatják az információt

- Hogyan

- Mi a célunk a kommunikációval

Példa: http://pasztor.freeblog.hu/files/Projekt%20kommunikáció.pdf

A legtöbb esetben a formátum standard vagy kötött, tehát létezik egy minta amit fel kell tölteni tartalommal. A trükk az, hogy ezeket a mintákat ismerjük, illetve azt felismerjük, hogy melyikre van szükségünk és melyikre nincs.

Mikor jó a kommunikáció? Erről nagy vita volt a rendezvényen, ezért saját definíciót használnék: akkor jó a kommunikáció, ha mindenki rendelkezik a munkavégzéshez szükséges információval. Például a fejlesztő tudja azt, hogy mik a felhasználók igényei, illetve a szponzor tisztában van a projekt aktuális állásával.

Honnan lehet tudni, hogy kinek milyen információra lesz szüksége? Ez adódik a projekt felépítéséből, az alkalmazott módszertanból és a korábbi tapasztalatból. Legrosszabb esetben kérdezni is lehet.

A jó kommunikáció annak a felelőssége, aki kommunikál. Figyelembe kell venni, hogy a „kommunikációs csatorna” zajos, és hogy a kommunikáció része a kódolás-dekódolás folyamat. Előfordulhat, hogy a hallgatóság másképp dekódolja az üzenetet, mint ahogyan a beszélő szerette volna – ezért figyelni kell az egyértelmű és tiszta üzenetekre, illetve fontos a hallgatóság visszajelzése.

Mennyire fontos az informális kommunikáció? Biztosan mindenkinek van egy vicces története arról, amikor a hivatalos út helyett valamit „szoft” módon, informális kommunikációval oldott meg. Az informális kommunikáció is fontos, néha csak ilyen úton lehet eljutni a sikerig, ennek ellenére én nem nevezném projekt kommunikációnak. Ugyanis az informális kommunikáció szerepe nem más, mint helyettesíteni vagy erősíteni a formálisat.

Hogyan lehet jól kommunikálni?

Mint ahogyan a PM műhelyhez kapcsolódó blogon olvashatjuk, a kommunikáció rendszerint akkor válik kritikus elemmé, amikor rossz – tehát utólag amikor egy projekt megbukik, akkor mondjuk azt, hogy a kudarc oka a rossz/gyenge kommunikáció volt.

Amikor a projekt megbukik, akkor már késő, ezért proaktívan, a projekt indulási fázisban (vagy még hamarabb) kell elkezdeni jól kommunikálni. Ehhez olyan menedzserekre van szükség, akik értenek hozzá. A kommunikációt meg lehet tanulni, jó lenne ha az egyetemen része lenne a tantervnek, de akár már középiskolában el lehet kezdeni. Kommunikációra szerintem minden embernek szüksége van, még a kockafejű informatikusoknak is. A menedzsereknek pedig „munkaköri kötelesség”.

Amikor egy menedzsert – különösen ha projekt menedzsert – vesznek fel, akkor a szakmai képességeken felül a kommunikációs képességeket is fel kell mérni. Na nem arra gondolok, hogy tud-e megnyerően beszélni a jelölt, hanem hogy ismeri-e a különböző kommunikációs csatornákat, és ezeket tudatosan, a helyzettől függően használja-e.

Aki nincs tisztában a kommunikációs modellel és a kommunikációs eszközökkel, az menjen el tanfolyamra. Sokat nyer vele.

Ps. Egyébként a kommunikációról itt már sokszor volt szó, például Jó koordinálás és jó kommunikáció – nem ugyanaz, A hatásos kommunikáció vagy Hogyan kommunikálj az IT-n belül?

Létezik-e szabad verseny az informatikai projektek tekintetében, tud-e pályázni és nyerni egy kisvállalat, folyik-e tisztességes szakmai munka?

A tegnapi A multi és a kkv viszonyáról bejegyzéshez BigTom beírt egy fontos kérdést:

Van szabad verseny?

Ezt szeretném kicsit kibontani, hiszen a bejegyzés maga sok kérdést hagy nyitva, illetve sok ok-okozati összefüggés nem lehet világos elsőre. Emberből vagyok és azt feltételeztem a cikk megírásakor, az Olvasó is tisztában van bizonyos törvényszerűségekkel.

Mert például én nem voltam ezekkel mindig tisztában.

Amikor még fiatal voltam, úgy képzeltem, hogy a szabad piaci verseny a minőséget erősíti, és hogy a jó munkásembernek érdeke versenyezni. A jó munkásember a munkájával és minőségével nyer – tehát az ideális világban minden informatikai projekt legyen tendereztetve, amely tenderre bármilyen vállalkozás bárhonnan jelentkezhet, és mindenki egyenlő módon lesz elbírálva. Tehát például legyen lehetősége megnyerni a nagy nemzetközi fejlesztési projektünket a kétfős szabolcsi vállalkozásnak.

A kapitalizmus, a szabad piaci verseny, a jog előtti egyenlőség valami ilyesmit diktál, nemdebár?

Nos, a valóság azért egy picit más, és erre megvan a logikus magyarázat.

A legfontosabb kényszer az, hogy a megrendelői oldal, tehát maga a nagyvállalat ahol a munkát el kell végezni, igen nagy és komplex. Még a belső IT sem dolgozik 100%-os sikerfaktorral, pedig ők a tűzhöz közel ülve minden információhoz hozzáférnek, minden szabályt ismernek és minden döntéshozóval kapcsolatban vannak.

Egy külső cég – bármennyire és jól dolgozik – nem ismeri a belső viszonyokat, a céges policy-kat, a belső audit-okat, és ezen felül nincs meg a hatalma, hogy keresztülvigyen rázós dolgokat. (A témáról részletesen olvashatsz a Lehet-e projektet vezetni kívülről? bejegyzésben)

A lényeg az, hogy egy új vállalkozó hendikeppel indul a tenderen a már ismert és bevált vállalkozókkal szemben, az alábbi okok miatt:

- A vállalkozó a megrendelői oldal „nem ismeretét”, illetve az ebből adódó kockázatokat kénytelen beárazni (vagy áttolni a megrendelői oldalra), emiatt magasabb lesz a „beszerzési költsége”.

- Az új vállalkozó plusz munkát jelent a megrendelői oldal számára – meg kell ismertetni a céges folyamatokkal, be kell tanítani. Szemben a már ismert vállalkozóval, aki ezeket alapból tudja.

- Az ismert vállalkozóról biztosan tudjuk, hogyan teljesít, az újat pedig nem ismerjük. Ez kockázat, amit a megrendelői oldal szeretne az árban érvényesíteni (tehát az ismeretlen vállalkozónak kevesebb fizetnénk, mert ki tudja mi történik).

- Az új vállalkozótól elvárjuk a jó referenciákat, miközben a már ismert vállalkozónak mi magunk vagyunk a referencia.

Összességében tehát egy új vállalkozás kockázat és költség, a régi jól bevált vállalkozó olcsó és stabil.

(Lásd még Mérő László: Kompromisszum)

A „best practice” szerint a projekteket nem tendereztetjük, hanem kialakítjuk a „jól bevált vállalkozók” körét – kiválasztunk vállalkozásokat stratégiai partnerségre, és utána minden felbukkanó munkát velük végeztetünk el. A velük kötött szerződés nem konkrét projektre szól, hanem kialakítunk egy együttműködési keretrendszer (pl. rögzítjük az óradíjakat, az átadási folyamatot, a minőséget definiáljuk), és utána az egyes projektek a keretszerződésen keresztül kerülnek végrehajtásra.

Ha egy kkv-nak sikerül ebbe a körbe belekerülni, akkor újabb és újabb megrendeléseket kap. Ha pedig nincs bent, de szeretne bejutni, az nagyon nehéz lesz.

Hogyan választjuk ki a beszállítót egy informatikai projektre?

Stratégiai beszállítókkal és keretszerződéssekkel dolgozunk, tehát amikor egy új informatikai projekt bukkan fel, akkor nem pályáztatunk, hanem az adott feladatra tartott „házi beszállítót” felhívjuk, hogy volna itt egy munka, adjon rá ajánlatot.

Hacsak a házi beszállító nem tiltakozik vagy nem ad szélsőségesen rossz ajánlatot, a megrendelés automatikusan az övé.

Most valaki mondhatja azt, hogy ez mennyire nem demokratikus, meg hogy biztosan nagy lehetőséget szalasztunk el, ha mindig ugyanattól veszünk fejlesztőket. Nos, volt már volt olyan eset, amikor egy projektre pályázatot írtunk ki, és vegyesen jelentkeztek „házi” és „ismeretlen” beszállítók. A házi beszállító nyert, hiszen sokkal magabiztosabb árat tudott adni, illetve vele szemben kisebbek voltak a kockázatok. Nem volt szükség „ismerősre” és nem kellett kigolyózni a riválisokat.

Az eset arra volt jó tanulság, hogy felesleges pályáztatni és külső jelentkezőket keresni, ha az ismert beszállítók is képesek szállítani.

Hogyan lehet bejutni egy új megrendelőhöz, hogy ott stratégiai partnerré váljunk?

Nagyon ritkán van ilyen lehetőség, hiszen az kell hozzá, hogy a meglévő beszállítók valamilyen okból kifolyólag ne legyenek alkalmasak. Ennek lehetnek politikai okai, lehet hogy megromlott a viszony, a projekt speciális, vagy a multi csak szondázza a piacot. Az a lényeg, hogy ilyen ritkán történik, és akkor ott lesz egy, azaz 1 darab lehetősége a kkv-nek. Nem több. Ha ezt az egy lehetőséget nem sikerül megragadni, akkor vége, lesz új beszállító és nincs szükség többre.

Vagyis a multihoz való bejutás türelem (megvárni a lehetőséget) és kemény munka (megragadni a lehetőséget) kérdése.

Amikor egy ilyen lehetőség adódik, hogyan lehet azt észrevenni és felkerülni a meghívottak listájára?

Amikor új beszállítót keresünk, akkor előbb azokat a cégeket listázzuk, akikkel valamilyen módon együtt dolgoztunk a múltban, nincsenek ellenérzéseink, és képesek lehetnek a munka elvégzésére. Nem csak a saját cégünknél nézünk szét, hanem a cégcsoport többi leányvállalatánál is.

Elsősorban olyan cégeket keresünk, aki bennünket ismer. Ha ilyen nincs, akkor olyat, aki legalább a cégcsoportot ismeri. Ha ilyen sincs, akkor olyat, aki az iparágban dolgozik, tehát van autóipari tapasztalata. Átlagos IT cégeket csak akkor keresünk meg, ha minden kötél szakad, vagy ha speciális a helyzet.

(Általában ha egy vállalkozás megkeres azzal, hogy nekünk dolgoznának, az első kérdésem, hogy van-e autóipari tapasztalata. Ha nincs, akkor úgyis találunk mást, akinek van.)

(Megjegyzés: A kiválasztást persze felülírhatja, ha valakinek az ismerősének az ismerőse, vagy ha valaki mutyizik. Csak hogy tisztázzuk: sem én, sem a beszerzőink nem korruptak.)

Vagyis a sikeres pályázás szempontjából vízválasztó a 0. lépés, amikor a vállalkozás pozícionálja magát, referenciákat gyűjt és kiépíti a kompetenciáit. A referenciák, a teljesített projektek és az üzleti kapcsolatok komoly értéket jelentenek. A „pénzért bármit megcsinálok” jellegű vállalkozások hátrányból indulnak.

Mennyire fontos az ár?

Létezik egy olyan közkeletű mítosz, hogy a legolcsóbb ajánlat nyer.

Van benne valami, három okból is:

1) A megrendelő azt szeretné, hogy a legalacsonyabb áron kapja meg a legjobb minőséget, ezért mindenféle csibészségre képes.

2) A piaci verseny azt jelenti, hogy mindenki a legalacsonyabb áron adja a legjobb minőséget (mármint ha üzletet akar)

3) A beszerzők teljesítményét ár alapján mérik

A „legalacsonyabb ár nyer” elv mögött sajnos sok esetben az húzódik, hogy a megrendelő oldalon nincs kompetencia, ezért nem tudják az áron kívül a többi tényezőt (pl minőség) összehasonlítani. Ugyanez az eset, ha van ugyan kompetens ember, de felülről megmondják neki a véleményét.

A helyes megoldás az, hogy az informatikai beszerzéseket az informatika és a beszerzés végzi közösen, vagy legalábbis részt vesznek a kiválasztási folyamatban.

Az 1. ponttal kapcsolatban megjegyezném, hogy sok esetben a beszerző egyszerűen csak bepróbálkozik, megvan a nyertes, de azt mondják neki, ha enged az árból 10%-ot akkor nyer. És enged, mert kell a munka.

Beszerzési ár alatti ajánlat, bevállalni az irreálisat?

BigTom megjegyzésében szerepelt az a jelenség, amikor a kkv bármit – szó szerint bármit, legyen szó akármilyen határidőről vagy árról – bevállal, csak hogy bekerüljön az ügyfélhez és referenciára tegyen szert.

A Mérő László-féle történet is arról szólt, hogy beszerzési ár alatt bevállaltak egy veszteséges projektet és fél év kemény munkát csak azért, hogy utána tisztességes elbírálás során tisztességes árral tudjanak versenyezni.

Megéri-e?

Erre lehetetlen így válaszolni, mindig az adott helyzettől függ.

A mérleg egyik oldalán az van, hogy ha a vállalkozás betette a lábát, utána már csökkennek a kockázatok, és majd a következő projekt nyereséges lesz. Sokkal inkább megéri kockáztatni, mint ügyfeleket veszíteni.

A mérleg másik oldalán az van, hogy a helyzet nyilván hosszú távon nem tartható. Ha a vállalkozó szerződésben vállalta a lehetetlen, akkor előfordulhat, hogy azt számon is kérik rajta. Lehet, hogy az ügyfél rövid távon alacsony árat szeretne, de hosszú távon pedig minőségi megoldásokat.

Meg kell találni a kettő között a járható utat, és ez a körülményektől, az ott dolgozó emberektől függ. Tanácsként azt tudnám ajánlani, hogy irreális árat be lehet vállalni üzletpolitikai okokból (pl. referencia projekt vagy pilot), de irreális határidőket vagy irreális leszállítandókat semmiképpen sem. Ugyanis az anyagi veszteséget még lehet valahogy utólag orvosolni, de a nem-teljesítés tényét nem lehet visszacsinálni.

Magyarul: az nem baj, ha ingyen dolgozunk, mert abban még lehet realitás, de ha a szakértők által minimum 6 hónaposra becsült fejlesztést 2 hónapra vállalunk be, akkor az biztosan nem lesz kész határidőre. Csodák nincsenek, az irreális elvárásokra épülő projektek szigorúan mindig összeomlanak.

Jó-e ez így?

Pályáztatás helyet stratégiai beszállítókat használni igenis jó, hiszen így a beszállító reális áron szállít reális határidőre, a megrendelő pedig minőséget kap és nem kockáztat.

Az új vállalkozásoknak és a körön kívülre rekedt kkv-knak ez a helyzet valószínűleg nem jó, hiszen ők nehezen kerülnek be.

De ez ellen nincs mit tenni, a helyzetet el kell fogadni.

Illetve lehet ellene tenni: referenciákat gyűjteni, megtartani a jó ügyfeleket, és megtanulni azt, hogy lehet élni a lehetőséggel. Mert nem minden vállalkozás tud élni a lehetőséggel, hiába nyitották ki előttük a kaput.

Ps. A végére még egy gondolat. Az IT az olcsó és standard megoldások irányába mozog, az informatikai költségvetés mindenhol csökken, vagy legalábbis nem növekszik. Zöld mezős informatikai beruházásból egyre kevesebb van. Mindez azt jelenti, hogy az ügyfelek egyre alacsonyabb árakat szeretnének, a beszállítók pedig kénytelenek egyre alacsonyabb áron szállítani ugyanazt. Ez van.

Létezik-e szabad verseny az informatikai projektek tekintetében, tud-e pályázni és nyerni egy kisvállalat, folyik-e tisztességes szakmai munka?

A tegnapi A multi és a kkv viszonyáról bejegyzéshez BigTom beírt egy fontos kérdést:

Van szabad verseny?

Ezt szeretném kicsit kibontani, hiszen a bejegyzés maga sok kérdést hagy nyitva, illetve sok ok-okozati összefüggés nem lehet világos elsőre. Emberből vagyok és azt feltételeztem a cikk megírásakor, az Olvasó is tisztában van bizonyos törvényszerűségekkel.

Mert például én nem voltam ezekkel mindig tisztában.

Amikor még fiatal voltam, úgy képzeltem, hogy a szabad piaci verseny a minőséget erősíti, és hogy a jó munkásembernek érdeke versenyezni. A jó munkásember a munkájával és minőségével nyer – tehát az ideális világban minden informatikai projekt legyen tendereztetve, amely tenderre bármilyen vállalkozás bárhonnan jelentkezhet, és mindenki egyenlő módon lesz elbírálva. Tehát például legyen lehetősége megnyerni a nagy nemzetközi fejlesztési projektünket a kétfős szabolcsi vállalkozásnak.

A kapitalizmus, a szabad piaci verseny, a jog előtti egyenlőség valami ilyesmit diktál, nemdebár?

Nos, a valóság azért egy picit más, és erre megvan a logikus magyarázat.

A legfontosabb kényszer az, hogy a megrendelői oldal, tehát maga a nagyvállalat ahol a munkát el kell végezni, igen nagy és komplex. Még a belső IT sem dolgozik 100%-os sikerfaktorral, pedig ők a tűzhöz közel ülve minden információhoz hozzáférnek, minden szabályt ismernek és minden döntéshozóval kapcsolatban vannak.

Egy külső cég – bármennyire és jól dolgozik – nem ismeri a belső viszonyokat, a céges policy-kat, a belső audit-okat, és ezen felül nincs meg a hatalma, hogy keresztülvigyen rázós dolgokat. (A témáról részletesen olvashatsz a Lehet-e projektet vezetni kívülről? bejegyzésben)

A lényeg az, hogy egy új vállalkozó hendikeppel indul a tenderen a már ismert és bevált vállalkozókkal szemben, az alábbi okok miatt:

- A vállalkozó a megrendelői oldal „nem ismeretét”, illetve az ebből adódó kockázatokat kénytelen beárazni (vagy áttolni a megrendelői oldalra), emiatt magasabb lesz a „beszerzési költsége”.

- Az új vállalkozó plusz munkát jelent a megrendelői oldal számára – meg kell ismertetni a céges folyamatokkal, be kell tanítani. Szemben a már ismert vállalkozóval, aki ezeket alapból tudja.

- Az ismert vállalkozóról biztosan tudjuk, hogyan teljesít, az újat pedig nem ismerjük. Ez kockázat, amit a megrendelői oldal szeretne az árban érvényesíteni (tehát az ismeretlen vállalkozónak kevesebb fizetnénk, mert ki tudja mi történik).

- Az új vállalkozótól elvárjuk a jó referenciákat, miközben a már ismert vállalkozónak mi magunk vagyunk a referencia.

Összességében tehát egy új vállalkozás kockázat és költség, a régi jól bevált vállalkozó olcsó és stabil.

(Lásd még Mérő László: Kompromisszum)

A „best practice” szerint a projekteket nem tendereztetjük, hanem kialakítjuk a „jól bevált vállalkozók” körét – kiválasztunk vállalkozásokat stratégiai partnerségre, és utána minden felbukkanó munkát velük végeztetünk el. A velük kötött szerződés nem konkrét projektre szól, hanem kialakítunk egy együttműködési keretrendszer (pl. rögzítjük az óradíjakat, az átadási folyamatot, a minőséget definiáljuk), és utána az egyes projektek a keretszerződésen keresztül kerülnek végrehajtásra.

Ha egy kkv-nak sikerül ebbe a körbe belekerülni, akkor újabb és újabb megrendeléseket kap. Ha pedig nincs bent, de szeretne bejutni, az nagyon nehéz lesz.

Hogyan választjuk ki a beszállítót egy informatikai projektre?

Stratégiai beszállítókkal és keretszerződéssekkel dolgozunk, tehát amikor egy új informatikai projekt bukkan fel, akkor nem pályáztatunk, hanem az adott feladatra tartott „házi beszállítót” felhívjuk, hogy volna itt egy munka, adjon rá ajánlatot.

Hacsak a házi beszállító nem tiltakozik vagy nem ad szélsőségesen rossz ajánlatot, a megrendelés automatikusan az övé.

Most valaki mondhatja azt, hogy ez mennyire nem demokratikus, meg hogy biztosan nagy lehetőséget szalasztunk el, ha mindig ugyanattól veszünk fejlesztőket. Nos, volt már volt olyan eset, amikor egy projektre pályázatot írtunk ki, és vegyesen jelentkeztek „házi” és „ismeretlen” beszállítók. A házi beszállító nyert, hiszen sokkal magabiztosabb árat tudott adni, illetve vele szemben kisebbek voltak a kockázatok. Nem volt szükség „ismerősre” és nem kellett kigolyózni a riválisokat.

Az eset arra volt jó tanulság, hogy felesleges pályáztatni és külső jelentkezőket keresni, ha az ismert beszállítók is képesek szállítani.

Hogyan lehet bejutni egy új megrendelőhöz, hogy ott stratégiai partnerré váljunk?

Nagyon ritkán van ilyen lehetőség, hiszen az kell hozzá, hogy a meglévő beszállítók valamilyen okból kifolyólag ne legyenek alkalmasak. Ennek lehetnek politikai okai, lehet hogy megromlott a viszony, a projekt speciális, vagy a multi csak szondázza a piacot. Az a lényeg, hogy ilyen ritkán történik, és akkor ott lesz egy, azaz 1 darab lehetősége a kkv-nek. Nem több. Ha ezt az egy lehetőséget nem sikerül megragadni, akkor vége, lesz új beszállító és nincs szükség többre.

Vagyis a multihoz való bejutás türelem (megvárni a lehetőséget) és kemény munka (megragadni a lehetőséget) kérdése.

Amikor egy ilyen lehetőség adódik, hogyan lehet azt észrevenni és felkerülni a meghívottak listájára?

Amikor új beszállítót keresünk, akkor előbb azokat a cégeket listázzuk, akikkel valamilyen módon együtt dolgoztunk a múltban, nincsenek ellenérzéseink, és képesek lehetnek a munka elvégzésére. Nem csak a saját cégünknél nézünk szét, hanem a cégcsoport többi leányvállalatánál is.

Elsősorban olyan cégeket keresünk, aki bennünket ismer. Ha ilyen nincs, akkor olyat, aki legalább a cégcsoportot ismeri. Ha ilyen sincs, akkor olyat, aki az iparágban dolgozik, tehát van autóipari tapasztalata. Átlagos IT cégeket csak akkor keresünk meg, ha minden kötél szakad, vagy ha speciális a helyzet.

(Általában ha egy vállalkozás megkeres azzal, hogy nekünk dolgoznának, az első kérdésem, hogy van-e autóipari tapasztalata. Ha nincs, akkor úgyis találunk mást, akinek van.)

(Megjegyzés: A kiválasztást persze felülírhatja, ha valakinek az ismerősének az ismerőse, vagy ha valaki mutyizik. Csak hogy tisztázzuk: sem én, sem a beszerzőink nem korruptak.)

Vagyis a sikeres pályázás szempontjából vízválasztó a 0. lépés, amikor a vállalkozás pozícionálja magát, referenciákat gyűjt és kiépíti a kompetenciáit. A referenciák, a teljesített projektek és az üzleti kapcsolatok komoly értéket jelentenek. A „pénzért bármit megcsinálok” jellegű vállalkozások hátrányból indulnak.

Mennyire fontos az ár?

Létezik egy olyan közkeletű mítosz, hogy a legolcsóbb ajánlat nyer.

Van benne valami, három okból is:

1) A megrendelő azt szeretné, hogy a legalacsonyabb áron kapja meg a legjobb minőséget, ezért mindenféle csibészségre képes.

2) A piaci verseny azt jelenti, hogy mindenki a legalacsonyabb áron adja a legjobb minőséget (mármint ha üzletet akar)

3) A beszerzők teljesítményét ár alapján mérik

A „legalacsonyabb ár nyer” elv mögött sajnos sok esetben az húzódik, hogy a megrendelő oldalon nincs kompetencia, ezért nem tudják az áron kívül a többi tényezőt (pl minőség) összehasonlítani. Ugyanez az eset, ha van ugyan kompetens ember, de felülről megmondják neki a véleményét.

A helyes megoldás az, hogy az informatikai beszerzéseket az informatika és a beszerzés végzi közösen, vagy legalábbis részt vesznek a kiválasztási folyamatban.

Az 1. ponttal kapcsolatban megjegyezném, hogy sok esetben a beszerző egyszerűen csak bepróbálkozik, megvan a nyertes, de azt mondják neki, ha enged az árból 10%-ot akkor nyer. És enged, mert kell a munka.

Beszerzési ár alatti ajánlat, bevállalni az irreálisat?

BigTom megjegyzésében szerepelt az a jelenség, amikor a kkv bármit – szó szerint bármit, legyen szó akármilyen határidőről vagy árról – bevállal, csak hogy bekerüljön az ügyfélhez és referenciára tegyen szert.

A Mérő László-féle történet is arról szólt, hogy beszerzési ár alatt bevállaltak egy veszteséges projektet és fél év kemény munkát csak azért, hogy utána tisztességes elbírálás során tisztességes árral tudjanak versenyezni.

Megéri-e?

Erre lehetetlen így válaszolni, mindig az adott helyzettől függ.

A mérleg egyik oldalán az van, hogy ha a vállalkozás betette a lábát, utána már csökkennek a kockázatok, és majd a következő projekt nyereséges lesz. Sokkal inkább megéri kockáztatni, mint ügyfeleket veszíteni.

A mérleg másik oldalán az van, hogy a helyzet nyilván hosszú távon nem tartható. Ha a vállalkozó szerződésben vállalta a lehetetlen, akkor előfordulhat, hogy azt számon is kérik rajta. Lehet, hogy az ügyfél rövid távon alacsony árat szeretne, de hosszú távon pedig minőségi megoldásokat.

Meg kell találni a kettő között a járható utat, és ez a körülményektől, az ott dolgozó emberektől függ. Tanácsként azt tudnám ajánlani, hogy irreális árat be lehet vállalni üzletpolitikai okokból (pl. referencia projekt vagy pilot), de irreális határidőket vagy irreális leszállítandókat semmiképpen sem. Ugyanis az anyagi veszteséget még lehet valahogy utólag orvosolni, de a nem-teljesítés tényét nem lehet visszacsinálni.

Magyarul: az nem baj, ha ingyen dolgozunk, mert abban még lehet realitás, de ha a szakértők által minimum 6 hónaposra becsült fejlesztést 2 hónapra vállalunk be, akkor az biztosan nem lesz kész határidőre. Csodák nincsenek, az irreális elvárásokra épülő projektek szigorúan mindig összeomlanak.

Jó-e ez így?

Pályáztatás helyet stratégiai beszállítókat használni igenis jó, hiszen így a beszállító reális áron szállít reális határidőre, a megrendelő pedig minőséget kap és nem kockáztat.

Az új vállalkozásoknak és a körön kívülre rekedt kkv-knak ez a helyzet valószínűleg nem jó, hiszen ők nehezen kerülnek be.

De ez ellen nincs mit tenni, a helyzetet el kell fogadni.

Illetve lehet ellene tenni: referenciákat gyűjteni, megtartani a jó ügyfeleket, és megtanulni azt, hogy lehet élni a lehetőséggel. Mert nem minden vállalkozás tud élni a lehetőséggel, hiába nyitották ki előttük a kaput.

Ps. A végére még egy gondolat. Az IT az olcsó és standard megoldások irányába mozog, az informatikai költségvetés mindenhol csökken, vagy legalábbis nem növekszik. Zöld mezős informatikai beruházásból egyre kevesebb van. Mindez azt jelenti, hogy az ügyfelek egyre alacsonyabb árakat szeretnének, a beszállítók pedig kénytelenek egyre alacsonyabb áron szállítani ugyanazt. Ez van.

Létezik-e szabad verseny az informatikai projektek tekintetében, tud-e pályázni és nyerni egy kisvállalat, folyik-e tisztességes szakmai munka?

A tegnapi A multi és a kkv viszonyáról bejegyzéshez BigTom beírt egy fontos kérdést:

Van szabad verseny?

Ezt szeretném kicsit kibontani, hiszen a bejegyzés maga sok kérdést hagy nyitva, illetve sok ok-okozati összefüggés nem lehet világos elsőre. Emberből vagyok és azt feltételeztem a cikk megírásakor, az Olvasó is tisztában van bizonyos törvényszerűségekkel.

Mert például én nem voltam ezekkel mindig tisztában.

Amikor még fiatal voltam, úgy képzeltem, hogy a szabad piaci verseny a minőséget erősíti, és hogy a jó munkásembernek érdeke versenyezni. A jó munkásember a munkájával és minőségével nyer – tehát az ideális világban minden informatikai projekt legyen tendereztetve, amely tenderre bármilyen vállalkozás bárhonnan jelentkezhet, és mindenki egyenlő módon lesz elbírálva. Tehát például legyen lehetősége megnyerni a nagy nemzetközi fejlesztési projektünket a kétfős szabolcsi vállalkozásnak.

A kapitalizmus, a szabad piaci verseny, a jog előtti egyenlőség valami ilyesmit diktál, nemdebár?

Nos, a valóság azért egy picit más, és erre megvan a logikus magyarázat.

A legfontosabb kényszer az, hogy a megrendelői oldal, tehát maga a nagyvállalat ahol a munkát el kell végezni, igen nagy és komplex. Még a belső IT sem dolgozik 100%-os sikerfaktorral, pedig ők a tűzhöz közel ülve minden információhoz hozzáférnek, minden szabályt ismernek és minden döntéshozóval kapcsolatban vannak.

Egy külső cég – bármennyire és jól dolgozik – nem ismeri a belső viszonyokat, a céges policy-kat, a belső audit-okat, és ezen felül nincs meg a hatalma, hogy keresztülvigyen rázós dolgokat. (A témáról részletesen olvashatsz a Lehet-e projektet vezetni kívülről? bejegyzésben)

A lényeg az, hogy egy új vállalkozó hendikeppel indul a tenderen a már ismert és bevált vállalkozókkal szemben, az alábbi okok miatt:

- A vállalkozó a megrendelői oldal „nem ismeretét”, illetve az ebből adódó kockázatokat kénytelen beárazni (vagy áttolni a megrendelői oldalra), emiatt magasabb lesz a „beszerzési költsége”.

- Az új vállalkozó plusz munkát jelent a megrendelői oldal számára – meg kell ismertetni a céges folyamatokkal, be kell tanítani. Szemben a már ismert vállalkozóval, aki ezeket alapból tudja.

- Az ismert vállalkozóról biztosan tudjuk, hogyan teljesít, az újat pedig nem ismerjük. Ez kockázat, amit a megrendelői oldal szeretne az árban érvényesíteni (tehát az ismeretlen vállalkozónak kevesebb fizetnénk, mert ki tudja mi történik).

- Az új vállalkozótól elvárjuk a jó referenciákat, miközben a már ismert vállalkozónak mi magunk vagyunk a referencia.

Összességében tehát egy új vállalkozás kockázat és költség, a régi jól bevált vállalkozó olcsó és stabil.

(Lásd még Mérő László: Kompromisszum)

A „best practice” szerint a projekteket nem tendereztetjük, hanem kialakítjuk a „jól bevált vállalkozók” körét – kiválasztunk vállalkozásokat stratégiai partnerségre, és utána minden felbukkanó munkát velük végeztetünk el. A velük kötött szerződés nem konkrét projektre szól, hanem kialakítunk egy együttműködési keretrendszer (pl. rögzítjük az óradíjakat, az átadási folyamatot, a minőséget definiáljuk), és utána az egyes projektek a keretszerződésen keresztül kerülnek végrehajtásra.

Ha egy kkv-nak sikerül ebbe a körbe belekerülni, akkor újabb és újabb megrendeléseket kap. Ha pedig nincs bent, de szeretne bejutni, az nagyon nehéz lesz.

Hogyan választjuk ki a beszállítót egy informatikai projektre?

Stratégiai beszállítókkal és keretszerződéssekkel dolgozunk, tehát amikor egy új informatikai projekt bukkan fel, akkor nem pályáztatunk, hanem az adott feladatra tartott „házi beszállítót” felhívjuk, hogy volna itt egy munka, adjon rá ajánlatot.

Hacsak a házi beszállító nem tiltakozik vagy nem ad szélsőségesen rossz ajánlatot, a megrendelés automatikusan az övé.

Most valaki mondhatja azt, hogy ez mennyire nem demokratikus, meg hogy biztosan nagy lehetőséget szalasztunk el, ha mindig ugyanattól veszünk fejlesztőket. Nos, volt már volt olyan eset, amikor egy projektre pályázatot írtunk ki, és vegyesen jelentkeztek „házi” és „ismeretlen” beszállítók. A házi beszállító nyert, hiszen sokkal magabiztosabb árat tudott adni, illetve vele szemben kisebbek voltak a kockázatok. Nem volt szükség „ismerősre” és nem kellett kigolyózni a riválisokat.

Az eset arra volt jó tanulság, hogy felesleges pályáztatni és külső jelentkezőket keresni, ha az ismert beszállítók is képesek szállítani.

Hogyan lehet bejutni egy új megrendelőhöz, hogy ott stratégiai partnerré váljunk?

Nagyon ritkán van ilyen lehetőség, hiszen az kell hozzá, hogy a meglévő beszállítók valamilyen okból kifolyólag ne legyenek alkalmasak. Ennek lehetnek politikai okai, lehet hogy megromlott a viszony, a projekt speciális, vagy a multi csak szondázza a piacot. Az a lényeg, hogy ilyen ritkán történik, és akkor ott lesz egy, azaz 1 darab lehetősége a kkv-nek. Nem több. Ha ezt az egy lehetőséget nem sikerül megragadni, akkor vége, lesz új beszállító és nincs szükség többre.

Vagyis a multihoz való bejutás türelem (megvárni a lehetőséget) és kemény munka (megragadni a lehetőséget) kérdése.

Amikor egy ilyen lehetőség adódik, hogyan lehet azt észrevenni és felkerülni a meghívottak listájára?

Amikor új beszállítót keresünk, akkor előbb azokat a cégeket listázzuk, akikkel valamilyen módon együtt dolgoztunk a múltban, nincsenek ellenérzéseink, és képesek lehetnek a munka elvégzésére. Nem csak a saját cégünknél nézünk szét, hanem a cégcsoport többi leányvállalatánál is.

Elsősorban olyan cégeket keresünk, aki bennünket ismer. Ha ilyen nincs, akkor olyat, aki legalább a cégcsoportot ismeri. Ha ilyen sincs, akkor olyat, aki az iparágban dolgozik, tehát van autóipari tapasztalata. Átlagos IT cégeket csak akkor keresünk meg, ha minden kötél szakad, vagy ha speciális a helyzet.

(Általában ha egy vállalkozás megkeres azzal, hogy nekünk dolgoznának, az első kérdésem, hogy van-e autóipari tapasztalata. Ha nincs, akkor úgyis találunk mást, akinek van.)

(Megjegyzés: A kiválasztást persze felülírhatja, ha valakinek az ismerősének az ismerőse, vagy ha valaki mutyizik. Csak hogy tisztázzuk: sem én, sem a beszerzőink nem korruptak.)

Vagyis a sikeres pályázás szempontjából vízválasztó a 0. lépés, amikor a vállalkozás pozícionálja magát, referenciákat gyűjt és kiépíti a kompetenciáit. A referenciák, a teljesített projektek és az üzleti kapcsolatok komoly értéket jelentenek. A „pénzért bármit megcsinálok” jellegű vállalkozások hátrányból indulnak.

Mennyire fontos az ár?

Létezik egy olyan közkeletű mítosz, hogy a legolcsóbb ajánlat nyer.

Van benne valami, három okból is:

1) A megrendelő azt szeretné, hogy a legalacsonyabb áron kapja meg a legjobb minőséget, ezért mindenféle csibészségre képes.

2) A piaci verseny azt jelenti, hogy mindenki a legalacsonyabb áron adja a legjobb minőséget (mármint ha üzletet akar)

3) A beszerzők teljesítményét ár alapján mérik

A „legalacsonyabb ár nyer” elv mögött sajnos sok esetben az húzódik, hogy a megrendelő oldalon nincs kompetencia, ezért nem tudják az áron kívül a többi tényezőt (pl minőség) összehasonlítani. Ugyanez az eset, ha van ugyan kompetens ember, de felülről megmondják neki a véleményét.

A helyes megoldás az, hogy az informatikai beszerzéseket az informatika és a beszerzés végzi közösen, vagy legalábbis részt vesznek a kiválasztási folyamatban.

Az 1. ponttal kapcsolatban megjegyezném, hogy sok esetben a beszerző egyszerűen csak bepróbálkozik, megvan a nyertes, de azt mondják neki, ha enged az árból 10%-ot akkor nyer. És enged, mert kell a munka.

Beszerzési ár alatti ajánlat, bevállalni az irreálisat?

BigTom megjegyzésében szerepelt az a jelenség, amikor a kkv bármit – szó szerint bármit, legyen szó akármilyen határidőről vagy árról – bevállal, csak hogy bekerüljön az ügyfélhez és referenciára tegyen szert.

A Mérő László-féle történet is arról szólt, hogy beszerzési ár alatt bevállaltak egy veszteséges projektet és fél év kemény munkát csak azért, hogy utána tisztességes elbírálás során tisztességes árral tudjanak versenyezni.

Megéri-e?

Erre lehetetlen így válaszolni, mindig az adott helyzettől függ.

A mérleg egyik oldalán az van, hogy ha a vállalkozás betette a lábát, utána már csökkennek a kockázatok, és majd a következő projekt nyereséges lesz. Sokkal inkább megéri kockáztatni, mint ügyfeleket veszíteni.

A mérleg másik oldalán az van, hogy a helyzet nyilván hosszú távon nem tartható. Ha a vállalkozó szerződésben vállalta a lehetetlen, akkor előfordulhat, hogy azt számon is kérik rajta. Lehet, hogy az ügyfél rövid távon alacsony árat szeretne, de hosszú távon pedig minőségi megoldásokat.

Meg kell találni a kettő között a járható utat, és ez a körülményektől, az ott dolgozó emberektől függ. Tanácsként azt tudnám ajánlani, hogy irreális árat be lehet vállalni üzletpolitikai okokból (pl. referencia projekt vagy pilot), de irreális határidőket vagy irreális leszállítandókat semmiképpen sem. Ugyanis az anyagi veszteséget még lehet valahogy utólag orvosolni, de a nem-teljesítés tényét nem lehet visszacsinálni.

Magyarul: az nem baj, ha ingyen dolgozunk, mert abban még lehet realitás, de ha a szakértők által minimum 6 hónaposra becsült fejlesztést 2 hónapra vállalunk be, akkor az biztosan nem lesz kész határidőre. Csodák nincsenek, az irreális elvárásokra épülő projektek szigorúan mindig összeomlanak.

Jó-e ez így?

Pályáztatás helyet stratégiai beszállítókat használni igenis jó, hiszen így a beszállító reális áron szállít reális határidőre, a megrendelő pedig minőséget kap és nem kockáztat.

Az új vállalkozásoknak és a körön kívülre rekedt kkv-knak ez a helyzet valószínűleg nem jó, hiszen ők nehezen kerülnek be.

De ez ellen nincs mit tenni, a helyzetet el kell fogadni.

Illetve lehet ellene tenni: referenciákat gyűjteni, megtartani a jó ügyfeleket, és megtanulni azt, hogy lehet élni a lehetőséggel. Mert nem minden vállalkozás tud élni a lehetőséggel, hiába nyitották ki előttük a kaput.

Ps. A végére még egy gondolat. Az IT az olcsó és standard megoldások irányába mozog, az informatikai költségvetés mindenhol csökken, vagy legalábbis nem növekszik. Zöld mezős informatikai beruházásból egyre kevesebb van. Mindez azt jelenti, hogy az ügyfelek egyre alacsonyabb árakat szeretnének, a beszállítók pedig kénytelenek egyre alacsonyabb áron szállítani ugyanazt. Ez van.

Létezik-e szabad verseny az informatikai projektek tekintetében, tud-e pályázni és nyerni egy kisvállalat, folyik-e tisztességes szakmai munka?

A tegnapi A multi és a kkv viszonyáról bejegyzéshez BigTom beírt egy fontos kérdést:

Van szabad verseny?

Ezt szeretném kicsit kibontani, hiszen a bejegyzés maga sok kérdést hagy nyitva, illetve sok ok-okozati összefüggés nem lehet világos elsőre. Emberből vagyok és azt feltételeztem a cikk megírásakor, az Olvasó is tisztában van bizonyos törvényszerűségekkel.

Mert például én nem voltam ezekkel mindig tisztában.

Amikor még fiatal voltam, úgy képzeltem, hogy a szabad piaci verseny a minőséget erősíti, és hogy a jó munkásembernek érdeke versenyezni. A jó munkásember a munkájával és minőségével nyer – tehát az ideális világban minden informatikai projekt legyen tendereztetve, amely tenderre bármilyen vállalkozás bárhonnan jelentkezhet, és mindenki egyenlő módon lesz elbírálva. Tehát például legyen lehetősége megnyerni a nagy nemzetközi fejlesztési projektünket a kétfős szabolcsi vállalkozásnak.

A kapitalizmus, a szabad piaci verseny, a jog előtti egyenlőség valami ilyesmit diktál, nemdebár?

Nos, a valóság azért egy picit más, és erre megvan a logikus magyarázat.

A legfontosabb kényszer az, hogy a megrendelői oldal, tehát maga a nagyvállalat ahol a munkát el kell végezni, igen nagy és komplex. Még a belső IT sem dolgozik 100%-os sikerfaktorral, pedig ők a tűzhöz közel ülve minden információhoz hozzáférnek, minden szabályt ismernek és minden döntéshozóval kapcsolatban vannak.

Egy külső cég – bármennyire és jól dolgozik – nem ismeri a belső viszonyokat, a céges policy-kat, a belső audit-okat, és ezen felül nincs meg a hatalma, hogy keresztülvigyen rázós dolgokat. (A témáról részletesen olvashatsz a Lehet-e projektet vezetni kívülről? bejegyzésben)

A lényeg az, hogy egy új vállalkozó hendikeppel indul a tenderen a már ismert és bevált vállalkozókkal szemben, az alábbi okok miatt:

- A vállalkozó a megrendelői oldal „nem ismeretét”, illetve az ebből adódó kockázatokat kénytelen beárazni (vagy áttolni a megrendelői oldalra), emiatt magasabb lesz a „beszerzési költsége”.

- Az új vállalkozó plusz munkát jelent a megrendelői oldal számára – meg kell ismertetni a céges folyamatokkal, be kell tanítani. Szemben a már ismert vállalkozóval, aki ezeket alapból tudja.

- Az ismert vállalkozóról biztosan tudjuk, hogyan teljesít, az újat pedig nem ismerjük. Ez kockázat, amit a megrendelői oldal szeretne az árban érvényesíteni (tehát az ismeretlen vállalkozónak kevesebb fizetnénk, mert ki tudja mi történik).

- Az új vállalkozótól elvárjuk a jó referenciákat, miközben a már ismert vállalkozónak mi magunk vagyunk a referencia.

Összességében tehát egy új vállalkozás kockázat és költség, a régi jól bevált vállalkozó olcsó és stabil.

(Lásd még Mérő László: Kompromisszum)

A „best practice” szerint a projekteket nem tendereztetjük, hanem kialakítjuk a „jól bevált vállalkozók” körét – kiválasztunk vállalkozásokat stratégiai partnerségre, és utána minden felbukkanó munkát velük végeztetünk el. A velük kötött szerződés nem konkrét projektre szól, hanem kialakítunk egy együttműködési keretrendszer (pl. rögzítjük az óradíjakat, az átadási folyamatot, a minőséget definiáljuk), és utána az egyes projektek a keretszerződésen keresztül kerülnek végrehajtásra.

Ha egy kkv-nak sikerül ebbe a körbe belekerülni, akkor újabb és újabb megrendeléseket kap. Ha pedig nincs bent, de szeretne bejutni, az nagyon nehéz lesz.

Hogyan választjuk ki a beszállítót egy informatikai projektre?

Stratégiai beszállítókkal és keretszerződéssekkel dolgozunk, tehát amikor egy új informatikai projekt bukkan fel, akkor nem pályáztatunk, hanem az adott feladatra tartott „házi beszállítót” felhívjuk, hogy volna itt egy munka, adjon rá ajánlatot.

Hacsak a házi beszállító nem tiltakozik vagy nem ad szélsőségesen rossz ajánlatot, a megrendelés automatikusan az övé.

Most valaki mondhatja azt, hogy ez mennyire nem demokratikus, meg hogy biztosan nagy lehetőséget szalasztunk el, ha mindig ugyanattól veszünk fejlesztőket. Nos, volt már volt olyan eset, amikor egy projektre pályázatot írtunk ki, és vegyesen jelentkeztek „házi” és „ismeretlen” beszállítók. A házi beszállító nyert, hiszen sokkal magabiztosabb árat tudott adni, illetve vele szemben kisebbek voltak a kockázatok. Nem volt szükség „ismerősre” és nem kellett kigolyózni a riválisokat.

Az eset arra volt jó tanulság, hogy felesleges pályáztatni és külső jelentkezőket keresni, ha az ismert beszállítók is képesek szállítani.

Hogyan lehet bejutni egy új megrendelőhöz, hogy ott stratégiai partnerré váljunk?

Nagyon ritkán van ilyen lehetőség, hiszen az kell hozzá, hogy a meglévő beszállítók valamilyen okból kifolyólag ne legyenek alkalmasak. Ennek lehetnek politikai okai, lehet hogy megromlott a viszony, a projekt speciális, vagy a multi csak szondázza a piacot. Az a lényeg, hogy ilyen ritkán történik, és akkor ott lesz egy, azaz 1 darab lehetősége a kkv-nek. Nem több. Ha ezt az egy lehetőséget nem sikerül megragadni, akkor vége, lesz új beszállító és nincs szükség többre.

Vagyis a multihoz való bejutás türelem (megvárni a lehetőséget) és kemény munka (megragadni a lehetőséget) kérdése.

Amikor egy ilyen lehetőség adódik, hogyan lehet azt észrevenni és felkerülni a meghívottak listájára?

Amikor új beszállítót keresünk, akkor előbb azokat a cégeket listázzuk, akikkel valamilyen módon együtt dolgoztunk a múltban, nincsenek ellenérzéseink, és képesek lehetnek a munka elvégzésére. Nem csak a saját cégünknél nézünk szét, hanem a cégcsoport többi leányvállalatánál is.

Elsősorban olyan cégeket keresünk, aki bennünket ismer. Ha ilyen nincs, akkor olyat, aki legalább a cégcsoportot ismeri. Ha ilyen sincs, akkor olyat, aki az iparágban dolgozik, tehát van autóipari tapasztalata. Átlagos IT cégeket csak akkor keresünk meg, ha minden kötél szakad, vagy ha speciális a helyzet.

(Általában ha egy vállalkozás megkeres azzal, hogy nekünk dolgoznának, az első kérdésem, hogy van-e autóipari tapasztalata. Ha nincs, akkor úgyis találunk mást, akinek van.)

(Megjegyzés: A kiválasztást persze felülírhatja, ha valakinek az ismerősének az ismerőse, vagy ha valaki mutyizik. Csak hogy tisztázzuk: sem én, sem a beszerzőink nem korruptak.)

Vagyis a sikeres pályázás szempontjából vízválasztó a 0. lépés, amikor a vállalkozás pozícionálja magát, referenciákat gyűjt és kiépíti a kompetenciáit. A referenciák, a teljesített projektek és az üzleti kapcsolatok komoly értéket jelentenek. A „pénzért bármit megcsinálok” jellegű vállalkozások hátrányból indulnak.

Mennyire fontos az ár?

Létezik egy olyan közkeletű mítosz, hogy a legolcsóbb ajánlat nyer.

Van benne valami, három okból is:

1) A megrendelő azt szeretné, hogy a legalacsonyabb áron kapja meg a legjobb minőséget, ezért mindenféle csibészségre képes.

2) A piaci verseny azt jelenti, hogy mindenki a legalacsonyabb áron adja a legjobb minőséget (mármint ha üzletet akar)

3) A beszerzők teljesítményét ár alapján mérik

A „legalacsonyabb ár nyer” elv mögött sajnos sok esetben az húzódik, hogy a megrendelő oldalon nincs kompetencia, ezért nem tudják az áron kívül a többi tényezőt (pl minőség) összehasonlítani. Ugyanez az eset, ha van ugyan kompetens ember, de felülről megmondják neki a véleményét.

A helyes megoldás az, hogy az informatikai beszerzéseket az informatika és a beszerzés végzi közösen, vagy legalábbis részt vesznek a kiválasztási folyamatban.

Az 1. ponttal kapcsolatban megjegyezném, hogy sok esetben a beszerző egyszerűen csak bepróbálkozik, megvan a nyertes, de azt mondják neki, ha enged az árból 10%-ot akkor nyer. És enged, mert kell a munka.

Beszerzési ár alatti ajánlat, bevállalni az irreálisat?

BigTom megjegyzésében szerepelt az a jelenség, amikor a kkv bármit – szó szerint bármit, legyen szó akármilyen határidőről vagy árról – bevállal, csak hogy bekerüljön az ügyfélhez és referenciára tegyen szert.

A Mérő László-féle történet is arról szólt, hogy beszerzési ár alatt bevállaltak egy veszteséges projektet és fél év kemény munkát csak azért, hogy utána tisztességes elbírálás során tisztességes árral tudjanak versenyezni.

Megéri-e?

Erre lehetetlen így válaszolni, mindig az adott helyzettől függ.

A mérleg egyik oldalán az van, hogy ha a vállalkozás betette a lábát, utána már csökkennek a kockázatok, és majd a következő projekt nyereséges lesz. Sokkal inkább megéri kockáztatni, mint ügyfeleket veszíteni.

A mérleg másik oldalán az van, hogy a helyzet nyilván hosszú távon nem tartható. Ha a vállalkozó szerződésben vállalta a lehetetlen, akkor előfordulhat, hogy azt számon is kérik rajta. Lehet, hogy az ügyfél rövid távon alacsony árat szeretne, de hosszú távon pedig minőségi megoldásokat.

Meg kell találni a kettő között a járható utat, és ez a körülményektől, az ott dolgozó emberektől függ. Tanácsként azt tudnám ajánlani, hogy irreális árat be lehet vállalni üzletpolitikai okokból (pl. referencia projekt vagy pilot), de irreális határidőket vagy irreális leszállítandókat semmiképpen sem. Ugyanis az anyagi veszteséget még lehet valahogy utólag orvosolni, de a nem-teljesítés tényét nem lehet visszacsinálni.

Magyarul: az nem baj, ha ingyen dolgozunk, mert abban még lehet realitás, de ha a szakértők által minimum 6 hónaposra becsült fejlesztést 2 hónapra vállalunk be, akkor az biztosan nem lesz kész határidőre. Csodák nincsenek, az irreális elvárásokra épülő projektek szigorúan mindig összeomlanak.

Jó-e ez így?

Pályáztatás helyet stratégiai beszállítókat használni igenis jó, hiszen így a beszállító reális áron szállít reális határidőre, a megrendelő pedig minőséget kap és nem kockáztat.

Az új vállalkozásoknak és a körön kívülre rekedt kkv-knak ez a helyzet valószínűleg nem jó, hiszen ők nehezen kerülnek be.

De ez ellen nincs mit tenni, a helyzetet el kell fogadni.

Illetve lehet ellene tenni: referenciákat gyűjteni, megtartani a jó ügyfeleket, és megtanulni azt, hogy lehet élni a lehetőséggel. Mert nem minden vállalkozás tud élni a lehetőséggel, hiába nyitották ki előttük a kaput.

Ps. A végére még egy gondolat. Az IT az olcsó és standard megoldások irányába mozog, az informatikai költségvetés mindenhol csökken, vagy legalábbis nem növekszik. Zöld mezős informatikai beruházásból egyre kevesebb van. Mindez azt jelenti, hogy az ügyfelek egyre alacsonyabb árakat szeretnének, a beszállítók pedig kénytelenek egyre alacsonyabb áron szállítani ugyanazt. Ez van.

Forrás: http://www.ezepic.hu/kepregeny/programozok-vs-felhasznalok

 

Forrás: http://www.ezepic.hu/kepregeny/programozok-vs-felhasznalok

 

süti beállítások módosítása