ITÉlet

Az empowerment leggyengébb láncszeme a vezető, erről szeretnék most bővebben írni

Mivel az empowerment egy fontos, de kevéssé ismert módszer, ezért 3 részes cikksorozatot szentelnék neki. A következő két részben a csapat felépítéséről és a magyar informatikusok sajátosságairól lesz szó, de most a legfontosabb dologgal kezdeném: a menedzserrel.

Kezdjük definícióval. Az empowerment (magyarul talán felhatalmazás) azt jelenti, hogy a beosztottak szabadságot kapnak, hogy feladataikban, feladataik végrehajtása során önállóan döntsenek. A döntési jog azzal jár, hogy növekszik a felelősségvállalás, a motiváció, és ezzel együtt a teljesítmény.

A pozitív hatások miatt az empowerment egyértelműen hasznos és kívánatos dolog – és akkor még nem is beszéltem a kreativitásról, az innovációról és a szervezeti hatékonyságról.

Természetesen nem minden esetben alkalmazható, nyilvánvalóan ez a körülmények függvénye. Az informatika például tipikusan az a terület, ahol alkalmazható.

Még mielőtt mindenki túlságosan belelkesülne: megvalósítani nem egyszerű. A legnehezebb dolog nem a csapat kiválasztása, felépítése vagy átalakítása, hanem annak a felismerése, hogy empowerment-re szükség van, és megtanulni az empowerment-hez szükséges eszközöket.

Ez ugyanis nem jön magától, nem reflexszerű. Amikor valakit váratlanul, mindenféle előzetes képzés nélkül kineveznek vezetőnek, akkor automatikusan a command-and-control-hoz nyúl: hatalmát felhasználva utasításokat ad, ellenőriz és büntet.

Sok vezető egész egyszerűen nem is hallott arról, hogy a csapatot fel is lehet hatalmazni. Nincs előttük példa, sosem látták, ezért számukra amolyan városi legenda lesz – semmi esetre sem próbálják meg „éles” környezetben.

Tehát amikor egy menedzser már hallott róla és utánanéz, már meg is tette a legjelentősebb lépést előre.

Hogyan sajátíthatja el egy vezető az empowerment művészetét?

Sajnos ez olyan dolog, amit könyvből vagy egy blogon olvasott érdekes cikk alapján nem lehet elsajátítani. A „learn on the job” a már korábban említett okok miatt nem működik.

Mindenképpen kell egy látható példa, egy jó vezető aki csinálja és akitől el lehet lesni a fortélyokat. Léteznek tanfolyamok - itt Magyarországon is – amikre el lehet menni és meg lehet tanulni.

Számomra az jelentette a fordulópontot, amikor külföldre mentem hosszabb időre dolgozni, és ott élesben láttam ezt működni. Annyira erős volt az élmény, hogy kvázi leradírozta a korábbi rossz vezetői mintákat, és beégette a helyeset. Éppen emiatt nem tudok konkrét, gyors utat adni az empowerment elsajátítására – nem tudok mondani könyv címet, amit az ember elolvasva megtanulja az alapokat.

Az empowerment elterjedését, a vezetők ezirányú szándékát jelentősen hátráltatja a téma elfogadottsága (illetve el nem fogadottsága) Magyarországon. A sikeres vezető sztereotípiájához hozzátartozik, hogy mindent keményen fog, és kitapossa a szuszt is a beosztottaiból. Amikor annak idején állást kerestem, és az interjún a pozitív hozzáállásról vagy a felhatalmazásról beszéltem, akkor bamba szemekkel néztek rám. Olyan megjegyzéseket kaptam, hogy „érdekes elmélet”.

Ez nyilvánvalóan egy ördögi kör: amíg a felhatalmazás nem elfogadott, addig diktátor típusú vezetőket keresnek, de amíg a diktátor típusúak vannak többségben, addig nem is fog elterjedni az empowerment.

A sikeres empowerment alkalmazásához feltétlenül szükséges a téma vállalaton belüli elfogadása (vagy legalábbis megtűrése), és a főnökünk pozitív hozzáállása. Sajnos sok helyen maga a céges kultúra teszi lehetetlenné a felhatalmazást. Akkor sem javasolnám kipróbálni, ha a főnökünk szerint „marhaság”.

Az empowerment elfogadásának feltétele, hogy a vállalat teljesítmény orientált legyen. Tehát amikor nem akarnak beleszólni a módszerekbe, amíg azok a módszerek hozzák az eredményt.

További feltétel, hogy – legalábbis a felszínen – az emberi értékek fontosak legyenek. A „respect people” nélkül nem megy.

Tegyük fel, hogy a vezető eldöntötte az empowerment bevezetését, ismeri is és látott is másokat ezt gyakorolni. Mi legyen a következő lépés, mit csináljon?

Az empowerment mindig a vezetővel kezdődik és a vezetővel végződik. A vezető az, aki elindítja a változást, ő változik először. 5 fő pontot említenék:

1) Vezető gondolkodásmódja

2) Erőforrások biztosítása

3) Információ megosztása

4) Jogkörök és döntési lehetőségek biztosítása

5) Csapat viselkedésének megváltozása

1) Vezető gondolkodásmódja

Mint írtam, a legelső lépés, hogy a vezető saját gondolkodásmódján változtat. A hagyományos feltételezés – „a beosztottak lopnak, csalnak, hazudnak” – helyett ennek pontosan az ellenkezőjét kell tenni: feltételezni, hogy a beosztottak jó szakértők és elvégzik a munkájukat. Mindenkiről a legjobbat kell gondolni (legalábbis addig, amíg ennek ellenkezőjét be nem bizonyítja).

Még akkor is, ha egy beosztott kevéssé képzett vagy nem a zsenialitás szobra, de tiszteljük meg mint embert és bánjunk vele normálisan.

Mindenképpen ez a legelső lépés, hiszen a vezetői példamutatás fogja beindítani a folyamatot.

2) Erőforrások biztosítása

Ahhoz, hogy a beosztottak képesek legyenek önállóan dönteni, el kell látni őket a munkájukhoz szükséges minden eszközre, alapanyagra, hozzáférésre és erőforrásra.

Ha a beosztottaknak lépten-nyomon a főnökükhöz kell rohangálni jóváhagyásokért és eszközöket kérni, akkor nem lesznek önállóak. A szükséges eszközök hiánya nem csak fizikailag, hanem mentálisan is gátolja a munkavégzést. Egyrészt ürügy lesz arra, hogy a munka ne haladjon, másrészt pedig a szükséges eszközök utáni rohangálás frusztrációt okoz és időt vesz el az értékteremtéstől.

Az erőforrások közé sorolom az olyan mentálhigiéniás dolgokat is, mint például kávéautomata, konyha, parkolóhely. Ha a beosztottak azt látják, hogy a főnökük MINDENT biztosít a munkavégzéshez, akkor az pozitív lökést ad számukra – arról nem is beszélve, hogy lecsökken a holt idő és nem veszik el feleslegesen munkaidő.

Megjegyzem, hogy az erőforrások biztosítása nem csak az empowerment miatt szükséges, hanem úgy általában is. Elvileg nem mondtam semmi újat.

3) Információ megosztása

Ahhoz, hogy a beosztottak önállóan végezhessék munkájukat, és döntéseket hozhassanak, információra van szükségük. Az információ is egyfajta erőforrás, ami nélkül nem lehet dolgozni.

Abból az alaptézisből kell kiindulni, hogy a kommunikációból sosem elég – vigyük szándékosan túlzásba!

A problémák JELENTŐS része abból származik, hogy valaki nem kapott meg egy számára szükséges információt. Ennek elkerülésére a következőket javaslom:

- Tudatosan derítsük fel és építsük ki a formális kommunikációs csatornákat – ügyfelekkel, vezetőkkel, számunkra fontos másik csapatokkal, a beosztottainkkal. A formális kommunikációnak alakuljanak ki a szabályai, tehát ki mikor kivel hogyan mit oszt meg (sablon dokumentumok és táblázatok használata)

- Szükség van rövid, de rendszeres csapaton belüli kommunikációra

- Osszunk meg minden információt azonnal!

- A kommunikáció legyen kétirányú: a beosztott tájékoztatja a főnökét, a főnök tájékoztatja a beosztottat. Mindkét irány ugyanannyira fontos!

- Legyen rendszeres privát megbeszélés a beosztottakkal

- A vezető készítsen hosszú távú tervet a csapat számára (stratégia) és ezt mindenki ismerje meg

- Visszajelzés: mind a pozitívumokról, mind a negatív dolgokról. Természetesen dicsérni mindenki előtt, nyilvánosan kell, negatív üzenetet pedig óvatosan és privát.

- Lehessen kérdezni a főnöktől.

Az információ gyors megosztásával az is elkerülhető, hogy rosszindulatú pletykák keringjenek. A rendszeres és gyors kommunikáció növeli a vezető iránti bizalmat, és növeli a csapat ellenállását a váratlan helyzetekkel szemben.

Bizonyos vezetők szeretik monopolizálni az információt, hiszen az információ hatalom. Azonban a hatalmat másképp is fent lehet tartani. Tükörbe kell nézni, és megkérdezni magunktól, hogy az információ monopóliumának feladásával megtartjuk-e az irányítást a csapat felett, vagy sem.

4) Döntési lehetőség biztosítása

Ha a beosztottak számára minden eszköz és információ rendelkezésre áll, akkor megnyílik a lehetőség, hogy a beosztottak döntsenek. Értelemszerűen amíg a feltételek nem adottak, addig nincs lehetőség jól dönteni.

Mit is értünk „döntés” alatt? A szakmai feladatokra vonatkozó szakmai döntéseket, egy adott feladatot hogyan oldjanak meg, vagy melyik feladatot először. Esetleg azt, hogy egy feladatot nem így kell elkezdeni, vagy az a feladat nem is feloldható.

Ez úgy érhető el, ha a vezető a „hogyan” helyett (mikromenedzsment) a célokra összpontosít. A beosztottaknak nem részletes utasításokat, hanem célokat kell adni, a célokhoz megvilágosítani a kontextust és a hátteret.

Azt kell feltételezni (és elvárni), hogy amennyiben a munkatársak akadállyal szembesülnek a feladat végrehajtása során, akkor majd eldöntik, hogyan oldják fel.

A vezető nem utasít, legfeljebb tanácsol vagy kérdez – vagyis alapvetően coaching-ol. Amikor műszaki kérdésről van szó, a vezető nem dönt, hanem megkérdezi a kérdéses beosztottat, hogy mi a véleménye. A csapat vezetése tehát elsősorban célok, és nem feladatok meghatározásával történik.

A döntési jog azt is jelentik, amennyiben a beosztott döntést hozott, azt a vezető elfogadja és támogatja. Előfordulhat például, hogy a döntés később hibásnak bizonyul – ilyen esetben is a vezetőnek maximálisan ki kell állnia a döntés és a beosztott mellett. (Természetesen amikor a  munkatárs sokszor dönt rosszul, az már orvoslandó eset)

Megjegyzem, hogy a vezetőnek amúgy is ki kell állnia a beosztottai és a döntések mellett, akár használja az empowerment-et, akár nem. Amikor valaki hibázik – emberek vagyunk, hibázunk – akkor sem szabad szembefordulni a csapattal.

5) Csapat hozzáállása

Természetesen ahhoz, hogy mindez működjön, szükség van a munkatársak megfelelő hozzáállása. A megfelelő hozzáállás alatt azt értem, hogy a munkatársak nem csak utasításra várnak, hanem képesek önállóan dolgozni, képesek egy váratlanul felbukkanó probléma esetén önállóan eldönteni, mi a helyes megoldás, képesek a helyes megoldást kivitelezni, és tisztában vannak a célok jelentőségével.

Sajnos ez nem olyan egyszerű. Ha valaki számára ismeretlen, idegen az empowerment, akkor eltart egy darabig, amíg a gondolkodásmódot a megfelelő irányba tereljük.

Erről fogok írni a következő cikkben.

Hogyan tudja elfogadtatni a menedzser a főnökével az empowerment-et?

Az empowerment csak egy eszköz, ezért nem jelent fundamentális változást a menedzser feladatait illetően. A csapatot továbbra is a menedzser vezeti, a végrehajtandó célok nem változnak, továbbra is van ellenőrzés, és aki nem teljesít az továbbra is repül a munkahelyéről.

Ilyen értelemben az empowerment nem jelent változást és nincs szükség „buy-in”-re.

Hozzátenném, hogy bizonyos méretek és szervezeti felépítés mellett az empowerment nem választás kérdése, hanem kötelező. Egy menedzser csak adott számú beosztottat tud közvetlenül felügyelni, ezen felül „kénytelen” megbízni bennük és bízni az önálló munkavégzésben.

Kinek a felelőssége az empowerment?

Csakis is kizárólag a vezetőé.

Milyen konfliktusokkal jár az empowerment alkalmazása?

Az 5-ös pontban említettek szerint a csapat „felépítése” lesz az elsődleges konfliktus.

Ezen felül konfliktus lehet/lesz a többi menedzserrel. Egy diktatórikus, hard eszközökkel operáló „rivális” menedzser szemében ugyanis az empowerment 180 fokos ellentéte a „normálisnak”, és ezért a felhatalmazó-támogató vezetőre úgy tekint, mint amatőrre. Pontosan ezért van szükség eredmény centrikus környezetre, ahol a csapat eredményessége elég bizonyíték lesz a módszer helyességére.

További konfliktusforrást jelenthet, ha az empowerment bevezetés sikeres lesz és a csapatunk motivált, miközben a többi csapat nem az. Aki nem lép egyszerre, nem kap rétest estére!

Az empowerment leggyengébb láncszeme a vezető, erről szeretnék most bővebben írni

Találós kérdés: mi az, amit a legtöbb szoftverfejlesztési szerződésből kifelejtenek?

A cikksorozat 1. része, 2. része, 3. része, 4. része, 5. része és 6. része után ismét előkerült a téma. Egy kollégám keresett meg azzal, hogy segítsek neki SLA-t írni.

Az történt, hogy egy projekt kapcsán külső beszállítóra volt szükségük, találtak egyet, egymás kezébe csaptak, majd megindult a munka. Viszont ahogy a projekt egyre inkább haladt a végkifejlet felé (átadás), elkezdtek azon gondolkodni, hogy mégis csak kellene valamilyen support – amiről korábban nem igazán beszéltek.

A helyzet – sajnos azt kell mondjam – elég tipikus. A legtöbb esetben, amikor valakinek új szoftverre, új web oldalra van szüksége, akkor csak odáig gondolkodik, hogy a munka el legyen végezve. Az átadás-átvételt, a fizetést, a késedelmet, a felmondást és a felelősséget jogi értelemben jól körbejárják – de az el szokott felejtődni, hogy mi történik a sikeres teljesítés UTÁN.

Mert ugye ilyenkor a beszállító megkapja a pénzét és levonul – a megrendelő pedig ott marad a szoftverrel. Ilyenkor már nincs tétje a rossz minőségnek és a nem-teljesítésnek, hiszen a programozó megkapta a pénzét. Innentől kezdve már pusztán személyes szimpátián múlik, hogy az utólagos problémákat orvosolják-e vagy sem. A szerződés annyit ér, amennyire betartják.

Ráadásul itt nem is arról van szó, hogy a beszállító rosszindulatú lenne, hanem egész egyszerűen neki ez nem betervezett munka, amire nincs erőforrása (a fejlesztők más projektre lettek allokálva), neki ez munkavégzéssel jár (a fejlesztőt ki kell fizetnie), viszont pénzt nem lát.

A valóság ugyebár az, hogy a szoftver sosem statikus. A szoftver idővel változik, hiszen az üzlet változik, a folyamatok változnak. Egy elkészült és átadott szoftver nem a történet vége, hanem éppen ellenkezőleg, a történet eleje. A kész szoftveren még rengeteg változtatás és hibajavítás fog történni. Éppen ezért a szoftverfejlesztési beszerzés során minden esetben ki kell térni az éles indulás utáni alkalmazás támogatásra, beleértve a hibajavítást, az új változtatásokat és a törvényi utánkövetést.

Fogalmak tisztázása végett: az SLA (Service Level Agreement) jelenti az alkalmazás támogatásra kötött megállapodást. Fizikai formája: szerződés, amelynek mellékletében, vagy amely alapján a felek megállapodnak a rendelkezésreállásban és a szolgáltatás minőségében.

Amikor megrendelünk egy új szoftvert, célszerű már akkor megbeszélni az SLA keretszámait és beletenni a szerződésbe.

Aki úgy gondolja, szétválaszthatja a kettőt (fejlesztési szerződés és támogatási szerződés) – a fejlesztési szerződést a projekt elején, a támogatási szerződést pedig a projekt végén aláírni.

Azonban mindenképpen fontos, hogy a keretszámok már az ajánlattételben szerepeljenek, későbbi félreértések elkerülése végett.

Kisméretű projektek, kkv-k esetén felesleges a papírmunkával vesződni, a két szolgáltatást egy közös szerződésbe be lehet rakni.

A lényeg annyi: ne úgy vegyünk szoftvert, mint kiló krumplit a piacon. Nem kell zseninek lenni, elég ha az alapvető dolgokra odafigyelünk, és ezzel nagyságrenddel lecsökkentjük a várható problémákat.

Mi a teendő, ha válságmenedzserként beledobnak egy olyan szituációba, amikor adott egy már meglévő szoftver, ami üzletileg kritikus, de elfelejtettek SLA-t megkötni, és emiatt rendelkezésre állási problémák, esetleg beszállítói problémák vannak?

A lehető leghamarabb le kell ülni a beszállítóval tárgyalni, hogy SLA-t kell kötni. A tiszta helyzet neki is érdeke. Az SLA azt jelenti, hogy a beszállító havonta fizetséget kap a rendelkezésre állásért és az alkalmazás támogatásért, cserébe viszont mérhető, számonkérhető módon biztosítja az alkalmazás működését.

Ha nincs SLA, akkor nincs mit számonkérni, de addig nincs is mire fizetni.

Találós kérdés: mi az, amit a legtöbb szoftverfejlesztési szerződésből kifelejtenek?

A cikksorozat 1. része, 2. része, 3. része, 4. része, 5. része és 6. része után ismét előkerült a téma. Egy kollégám keresett meg azzal, hogy segítsek neki SLA-t írni.

Az történt, hogy egy projekt kapcsán külső beszállítóra volt szükségük, találtak egyet, egymás kezébe csaptak, majd megindult a munka. Viszont ahogy a projekt egyre inkább haladt a végkifejlet felé (átadás), elkezdtek azon gondolkodni, hogy mégis csak kellene valamilyen support – amiről korábban nem igazán beszéltek.

A helyzet – sajnos azt kell mondjam – elég tipikus. A legtöbb esetben, amikor valakinek új szoftverre, új web oldalra van szüksége, akkor csak odáig gondolkodik, hogy a munka el legyen végezve. Az átadás-átvételt, a fizetést, a késedelmet, a felmondást és a felelősséget jogi értelemben jól körbejárják – de az el szokott felejtődni, hogy mi történik a sikeres teljesítés UTÁN.

Mert ugye ilyenkor a beszállító megkapja a pénzét és levonul – a megrendelő pedig ott marad a szoftverrel. Ilyenkor már nincs tétje a rossz minőségnek és a nem-teljesítésnek, hiszen a programozó megkapta a pénzét. Innentől kezdve már pusztán személyes szimpátián múlik, hogy az utólagos problémákat orvosolják-e vagy sem. A szerződés annyit ér, amennyire betartják.

Ráadásul itt nem is arról van szó, hogy a beszállító rosszindulatú lenne, hanem egész egyszerűen neki ez nem betervezett munka, amire nincs erőforrása (a fejlesztők más projektre lettek allokálva), neki ez munkavégzéssel jár (a fejlesztőt ki kell fizetnie), viszont pénzt nem lát.

A valóság ugyebár az, hogy a szoftver sosem statikus. A szoftver idővel változik, hiszen az üzlet változik, a folyamatok változnak. Egy elkészült és átadott szoftver nem a történet vége, hanem éppen ellenkezőleg, a történet eleje. A kész szoftveren még rengeteg változtatás és hibajavítás fog történni. Éppen ezért a szoftverfejlesztési beszerzés során minden esetben ki kell térni az éles indulás utáni alkalmazás támogatásra, beleértve a hibajavítást, az új változtatásokat és a törvényi utánkövetést.

Fogalmak tisztázása végett: az SLA (Service Level Agreement) jelenti az alkalmazás támogatásra kötött megállapodást. Fizikai formája: szerződés, amelynek mellékletében, vagy amely alapján a felek megállapodnak a rendelkezésreállásban és a szolgáltatás minőségében.

Amikor megrendelünk egy új szoftvert, célszerű már akkor megbeszélni az SLA keretszámait és beletenni a szerződésbe.

Aki úgy gondolja, szétválaszthatja a kettőt (fejlesztési szerződés és támogatási szerződés) – a fejlesztési szerződést a projekt elején, a támogatási szerződést pedig a projekt végén aláírni.

Azonban mindenképpen fontos, hogy a keretszámok már az ajánlattételben szerepeljenek, későbbi félreértések elkerülése végett.

Kisméretű projektek, kkv-k esetén felesleges a papírmunkával vesződni, a két szolgáltatást egy közös szerződésbe be lehet rakni.

A lényeg annyi: ne úgy vegyünk szoftvert, mint kiló krumplit a piacon. Nem kell zseninek lenni, elég ha az alapvető dolgokra odafigyelünk, és ezzel nagyságrenddel lecsökkentjük a várható problémákat.

Mi a teendő, ha válságmenedzserként beledobnak egy olyan szituációba, amikor adott egy már meglévő szoftver, ami üzletileg kritikus, de elfelejtettek SLA-t megkötni, és emiatt rendelkezésre állási problémák, esetleg beszállítói problémák vannak?

A lehető leghamarabb le kell ülni a beszállítóval tárgyalni, hogy SLA-t kell kötni. A tiszta helyzet neki is érdeke. Az SLA azt jelenti, hogy a beszállító havonta fizetséget kap a rendelkezésre állásért és az alkalmazás támogatásért, cserébe viszont mérhető, számonkérhető módon biztosítja az alkalmazás működését.

Ha nincs SLA, akkor nincs mit számonkérni, de addig nincs is mire fizetni.

Találós kérdés: mi az, amit a legtöbb szoftverfejlesztési szerződésből kifelejtenek?

A cikksorozat 1. része, 2. része, 3. része, 4. része, 5. része és 6. része után ismét előkerült a téma. Egy kollégám keresett meg azzal, hogy segítsek neki SLA-t írni.

Az történt, hogy egy projekt kapcsán külső beszállítóra volt szükségük, találtak egyet, egymás kezébe csaptak, majd megindult a munka. Viszont ahogy a projekt egyre inkább haladt a végkifejlet felé (átadás), elkezdtek azon gondolkodni, hogy mégis csak kellene valamilyen support – amiről korábban nem igazán beszéltek.

A helyzet – sajnos azt kell mondjam – elég tipikus. A legtöbb esetben, amikor valakinek új szoftverre, új web oldalra van szüksége, akkor csak odáig gondolkodik, hogy a munka el legyen végezve. Az átadás-átvételt, a fizetést, a késedelmet, a felmondást és a felelősséget jogi értelemben jól körbejárják – de az el szokott felejtődni, hogy mi történik a sikeres teljesítés UTÁN.

Mert ugye ilyenkor a beszállító megkapja a pénzét és levonul – a megrendelő pedig ott marad a szoftverrel. Ilyenkor már nincs tétje a rossz minőségnek és a nem-teljesítésnek, hiszen a programozó megkapta a pénzét. Innentől kezdve már pusztán személyes szimpátián múlik, hogy az utólagos problémákat orvosolják-e vagy sem. A szerződés annyit ér, amennyire betartják.

Ráadásul itt nem is arról van szó, hogy a beszállító rosszindulatú lenne, hanem egész egyszerűen neki ez nem betervezett munka, amire nincs erőforrása (a fejlesztők más projektre lettek allokálva), neki ez munkavégzéssel jár (a fejlesztőt ki kell fizetnie), viszont pénzt nem lát.

A valóság ugyebár az, hogy a szoftver sosem statikus. A szoftver idővel változik, hiszen az üzlet változik, a folyamatok változnak. Egy elkészült és átadott szoftver nem a történet vége, hanem éppen ellenkezőleg, a történet eleje. A kész szoftveren még rengeteg változtatás és hibajavítás fog történni. Éppen ezért a szoftverfejlesztési beszerzés során minden esetben ki kell térni az éles indulás utáni alkalmazás támogatásra, beleértve a hibajavítást, az új változtatásokat és a törvényi utánkövetést.

Fogalmak tisztázása végett: az SLA (Service Level Agreement) jelenti az alkalmazás támogatásra kötött megállapodást. Fizikai formája: szerződés, amelynek mellékletében, vagy amely alapján a felek megállapodnak a rendelkezésreállásban és a szolgáltatás minőségében.

Amikor megrendelünk egy új szoftvert, célszerű már akkor megbeszélni az SLA keretszámait és beletenni a szerződésbe.

Aki úgy gondolja, szétválaszthatja a kettőt (fejlesztési szerződés és támogatási szerződés) – a fejlesztési szerződést a projekt elején, a támogatási szerződést pedig a projekt végén aláírni.

Azonban mindenképpen fontos, hogy a keretszámok már az ajánlattételben szerepeljenek, későbbi félreértések elkerülése végett.

Kisméretű projektek, kkv-k esetén felesleges a papírmunkával vesződni, a két szolgáltatást egy közös szerződésbe be lehet rakni.

A lényeg annyi: ne úgy vegyünk szoftvert, mint kiló krumplit a piacon. Nem kell zseninek lenni, elég ha az alapvető dolgokra odafigyelünk, és ezzel nagyságrenddel lecsökkentjük a várható problémákat.

Mi a teendő, ha válságmenedzserként beledobnak egy olyan szituációba, amikor adott egy már meglévő szoftver, ami üzletileg kritikus, de elfelejtettek SLA-t megkötni, és emiatt rendelkezésre állási problémák, esetleg beszállítói problémák vannak?

A lehető leghamarabb le kell ülni a beszállítóval tárgyalni, hogy SLA-t kell kötni. A tiszta helyzet neki is érdeke. Az SLA azt jelenti, hogy a beszállító havonta fizetséget kap a rendelkezésre állásért és az alkalmazás támogatásért, cserébe viszont mérhető, számonkérhető módon biztosítja az alkalmazás működését.

Ha nincs SLA, akkor nincs mit számonkérni, de addig nincs is mire fizetni.

Találós kérdés: mi az, amit a legtöbb szoftverfejlesztési szerződésből kifelejtenek?

Mi a közös a búzában és a multinacionális cégben? Hát a siló.

A siló ömlesztett liszt, cukor, vagy szemestermény tárolására szolgáló épület vagy berendezés. Hosszú és egyenes. Kép itt található róla: http://upload.wikimedia.org/wikipedia/commons/1/14/Port_Giles_silos.jpg

Ismert még a rakétasiló, ami a nevét onnan kapta, hogy hasonlít a silóra, csak mást tárolnak benne.

Egy vállalat a siló az egymástól elkülönülő szervezeteket jelenti, amelyek a hagyományos silókhoz hasonlóan nagyok, tömörek, zártak, és egymással párhuzamosan, de össze nem kapcsolódva futnak. Mindegyik siló egy-egy zárt világ, amelyik igyekszik a többiekről tudomást sem venni.

Ilyen silók lehetnek például a pénzügy, a marketing, az értékesítés vagy az informatika. Mindegyik területnek megvannak a saját szokásai, belső szabályai, alapismeretei, és a hozzá szükséges iskola végzettség. Az egyes területek – silók – között nincs átjárás. Az informatikai vezetőből sosem lesz pénzügyi vezető, az értékesítő pedig sosem kerül át az informatikára.

A belső nyelv és a viselkedésminta is más. Ahogyan a pénzügyesek beszélnek, az mások számára nem érthető, és minimum egy közgazdász kell hozzá, hogy a többiek számára lefordítsa a sok okosság értelmét. De amikor informatikusok beszélgetnek egymás között, na ahhoz is fordítógép kell.

A silók nem csak a szervezeti ábrán jelentkeznek, hanem az informatikai rendszereken. Van a pénzügynek egy könyvelési, számlázási rendszere, van az értékesítésnek egy rendelési, értékesítési rendszere, a marketingnek pedig van egy céges web oldala. Mindegyik külön rendszer, külön fejlesztőkkel és külön informatikai támogatással.

Azt mondják, hogy a silók létezése káros a cégre nézve. A siló ugyanis lezárja a külső információáramlást. A pénzügy nem tudja, miben mesterkedik a marketing, ezért nem tudja azt segíteni, támogatni vagy tanácsot adni. Vagy fordítva.

Tehát az egyes osztályok miközben saját területükhöz nagyon jól értenek, de minimális információjuk és támogatásuk lesz mindenben, ami más osztályok munkájához kapcsolódik.

A helyzet azonban az, hogy egy nagyvállalatnál sok olyan munka és folyamat van, ami egyszerre több osztályt érint. Ilyen például a márkakereskedőkkel szembeni elszámolás, amihez egyik oldalról szükség van a tényleges teljesítésre (logisztika), másik oldalról viszont a számlákra (pénzügy).

Arról nem is beszélve, hogy az egyes osztályok ellenségként viselkednek – hiszen egymás vetélytársai az élelemért (budget) folytatott harcban.

Ezért a több osztályt érintő feladatok és folyamatok nehezen szoktak menni, és ezáltal kár éri a céget.

Több módszer ismert a silók feltörésére és megszüntetésére, illetve a silók közötti együttműködés erősítésére.

Kérdés persze, hogy ezekre mennyire van szükség.

Ugyanis az informatikai mindig informatika marad, a maga sajátosságaival – a pénzügy pedig pénzügy, a marketing az marketing, és az értékesítés az értékesítés. Ezeket a területeket nem lehet ugyanúgy, ugyanolyan módon, ugyanazokkal a módszerekkel kezelni. Vagy legalábbis az nem lesz tökéletes.

Az egyedi szakterületek – mármint ha jól csinálják – megkövetelik azt, hogy a szakértők gondolkodásmódja idomuljon, a rendszereik az egyedi igényeket és sajátosságokat kielégítsék. Nem lehet ugyanúgy fejleszteni szoftvert egy könyvelő számára, egy marketingesnek, egy értékesítőnek vagy egy mérnöknek. Mindegyik egész mást vár el a programozótól, mindegyik azt akarja, hogy a programozó értse az üzleti igényeket és beszélje az üzleti nyelvet. Nem létezik „univerzális” szoftverfejlesztés.

Akkor miért képeznek az egyetemek „univerzális” szoftverfejlesztőket? Mert lehetetlen lenne minden egyes szakterület egyedi igényei után szaladgálni – és kétséges is lenne, hogy egy specialista kapna-e munkát. Ha szerencséje van és éppen sok munka van a piacon az adott szakterületen, akkor jó sokat kereshetne, ellenben ha éppen nincsen munka valami miatt, akkor értéktelenné válik a tudása.

Ennél már hasznosabb az olyan pályakezdő informatikus, aki még nem specializálódott, de az alapokkal tisztában van, és majd a piaci igényeknek megfelelően specializálódik (felépíti karrierét).

A legeslegjobb viszont az lenne, ha a felsőoktatás érzékenyen követné a piacot, és lehetőséget adna specializálódni – például banki fejlesztőre mindig szükség lesz, mint ahogy telekomos programozóra vagy ipari automatizálásra is.

Kicsit elkalandoztam, vissza a silókhoz!

Hogyan lehet hatékonyan kezelni a silókat informatikai szempontból? Ez attól függ, hogy cég stratégiájában mi az informatika szerepe. De a leggyakoribb megoldás az, amikor az IT a cég szervezeti struktúráját lekövetve specializálódik, azaz minden egyes silóhoz létezik egy informatikai csapat, amelyik az adott siló szoftvereit és igényeit kezeli. Tehát létezik pénzügyi informatikai csapat, marketing informatika, értékesítési informatika, stb.

Mi a közös a búzában és a multinacionális cégben? Hát a siló.

A siló ömlesztett liszt, cukor, vagy szemestermény tárolására szolgáló épület vagy berendezés. Hosszú és egyenes. Kép itt található róla: http://upload.wikimedia.org/wikipedia/commons/1/14/Port_Giles_silos.jpg

Ismert még a rakétasiló, ami a nevét onnan kapta, hogy hasonlít a silóra, csak mást tárolnak benne.

Egy vállalat a siló az egymástól elkülönülő szervezeteket jelenti, amelyek a hagyományos silókhoz hasonlóan nagyok, tömörek, zártak, és egymással párhuzamosan, de össze nem kapcsolódva futnak. Mindegyik siló egy-egy zárt világ, amelyik igyekszik a többiekről tudomást sem venni.

Ilyen silók lehetnek például a pénzügy, a marketing, az értékesítés vagy az informatika. Mindegyik területnek megvannak a saját szokásai, belső szabályai, alapismeretei, és a hozzá szükséges iskola végzettség. Az egyes területek – silók – között nincs átjárás. Az informatikai vezetőből sosem lesz pénzügyi vezető, az értékesítő pedig sosem kerül át az informatikára.

A belső nyelv és a viselkedésminta is más. Ahogyan a pénzügyesek beszélnek, az mások számára nem érthető, és minimum egy közgazdász kell hozzá, hogy a többiek számára lefordítsa a sok okosság értelmét. De amikor informatikusok beszélgetnek egymás között, na ahhoz is fordítógép kell.

A silók nem csak a szervezeti ábrán jelentkeznek, hanem az informatikai rendszereken. Van a pénzügynek egy könyvelési, számlázási rendszere, van az értékesítésnek egy rendelési, értékesítési rendszere, a marketingnek pedig van egy céges web oldala. Mindegyik külön rendszer, külön fejlesztőkkel és külön informatikai támogatással.

Azt mondják, hogy a silók létezése káros a cégre nézve. A siló ugyanis lezárja a külső információáramlást. A pénzügy nem tudja, miben mesterkedik a marketing, ezért nem tudja azt segíteni, támogatni vagy tanácsot adni. Vagy fordítva.

Tehát az egyes osztályok miközben saját területükhöz nagyon jól értenek, de minimális információjuk és támogatásuk lesz mindenben, ami más osztályok munkájához kapcsolódik.

A helyzet azonban az, hogy egy nagyvállalatnál sok olyan munka és folyamat van, ami egyszerre több osztályt érint. Ilyen például a márkakereskedőkkel szembeni elszámolás, amihez egyik oldalról szükség van a tényleges teljesítésre (logisztika), másik oldalról viszont a számlákra (pénzügy).

Arról nem is beszélve, hogy az egyes osztályok ellenségként viselkednek – hiszen egymás vetélytársai az élelemért (budget) folytatott harcban.

Ezért a több osztályt érintő feladatok és folyamatok nehezen szoktak menni, és ezáltal kár éri a céget.

Több módszer ismert a silók feltörésére és megszüntetésére, illetve a silók közötti együttműködés erősítésére.

Kérdés persze, hogy ezekre mennyire van szükség.

Ugyanis az informatikai mindig informatika marad, a maga sajátosságaival – a pénzügy pedig pénzügy, a marketing az marketing, és az értékesítés az értékesítés. Ezeket a területeket nem lehet ugyanúgy, ugyanolyan módon, ugyanazokkal a módszerekkel kezelni. Vagy legalábbis az nem lesz tökéletes.

Az egyedi szakterületek – mármint ha jól csinálják – megkövetelik azt, hogy a szakértők gondolkodásmódja idomuljon, a rendszereik az egyedi igényeket és sajátosságokat kielégítsék. Nem lehet ugyanúgy fejleszteni szoftvert egy könyvelő számára, egy marketingesnek, egy értékesítőnek vagy egy mérnöknek. Mindegyik egész mást vár el a programozótól, mindegyik azt akarja, hogy a programozó értse az üzleti igényeket és beszélje az üzleti nyelvet. Nem létezik „univerzális” szoftverfejlesztés.

Akkor miért képeznek az egyetemek „univerzális” szoftverfejlesztőket? Mert lehetetlen lenne minden egyes szakterület egyedi igényei után szaladgálni – és kétséges is lenne, hogy egy specialista kapna-e munkát. Ha szerencséje van és éppen sok munka van a piacon az adott szakterületen, akkor jó sokat kereshetne, ellenben ha éppen nincsen munka valami miatt, akkor értéktelenné válik a tudása.

Ennél már hasznosabb az olyan pályakezdő informatikus, aki még nem specializálódott, de az alapokkal tisztában van, és majd a piaci igényeknek megfelelően specializálódik (felépíti karrierét).

A legeslegjobb viszont az lenne, ha a felsőoktatás érzékenyen követné a piacot, és lehetőséget adna specializálódni – például banki fejlesztőre mindig szükség lesz, mint ahogy telekomos programozóra vagy ipari automatizálásra is.

Kicsit elkalandoztam, vissza a silókhoz!

Hogyan lehet hatékonyan kezelni a silókat informatikai szempontból? Ez attól függ, hogy cég stratégiájában mi az informatika szerepe. De a leggyakoribb megoldás az, amikor az IT a cég szervezeti struktúráját lekövetve specializálódik, azaz minden egyes silóhoz létezik egy informatikai csapat, amelyik az adott siló szoftvereit és igényeit kezeli. Tehát létezik pénzügyi informatikai csapat, marketing informatika, értékesítési informatika, stb.

Mi a közös a búzában és a multinacionális cégben? Hát a siló.

A siló ömlesztett liszt, cukor, vagy szemestermény tárolására szolgáló épület vagy berendezés. Hosszú és egyenes. Kép itt található róla: http://upload.wikimedia.org/wikipedia/commons/1/14/Port_Giles_silos.jpg

Ismert még a rakétasiló, ami a nevét onnan kapta, hogy hasonlít a silóra, csak mást tárolnak benne.

Egy vállalat a siló az egymástól elkülönülő szervezeteket jelenti, amelyek a hagyományos silókhoz hasonlóan nagyok, tömörek, zártak, és egymással párhuzamosan, de össze nem kapcsolódva futnak. Mindegyik siló egy-egy zárt világ, amelyik igyekszik a többiekről tudomást sem venni.

Ilyen silók lehetnek például a pénzügy, a marketing, az értékesítés vagy az informatika. Mindegyik területnek megvannak a saját szokásai, belső szabályai, alapismeretei, és a hozzá szükséges iskola végzettség. Az egyes területek – silók – között nincs átjárás. Az informatikai vezetőből sosem lesz pénzügyi vezető, az értékesítő pedig sosem kerül át az informatikára.

A belső nyelv és a viselkedésminta is más. Ahogyan a pénzügyesek beszélnek, az mások számára nem érthető, és minimum egy közgazdász kell hozzá, hogy a többiek számára lefordítsa a sok okosság értelmét. De amikor informatikusok beszélgetnek egymás között, na ahhoz is fordítógép kell.

A silók nem csak a szervezeti ábrán jelentkeznek, hanem az informatikai rendszereken. Van a pénzügynek egy könyvelési, számlázási rendszere, van az értékesítésnek egy rendelési, értékesítési rendszere, a marketingnek pedig van egy céges web oldala. Mindegyik külön rendszer, külön fejlesztőkkel és külön informatikai támogatással.

Azt mondják, hogy a silók létezése káros a cégre nézve. A siló ugyanis lezárja a külső információáramlást. A pénzügy nem tudja, miben mesterkedik a marketing, ezért nem tudja azt segíteni, támogatni vagy tanácsot adni. Vagy fordítva.

Tehát az egyes osztályok miközben saját területükhöz nagyon jól értenek, de minimális információjuk és támogatásuk lesz mindenben, ami más osztályok munkájához kapcsolódik.

A helyzet azonban az, hogy egy nagyvállalatnál sok olyan munka és folyamat van, ami egyszerre több osztályt érint. Ilyen például a márkakereskedőkkel szembeni elszámolás, amihez egyik oldalról szükség van a tényleges teljesítésre (logisztika), másik oldalról viszont a számlákra (pénzügy).

Arról nem is beszélve, hogy az egyes osztályok ellenségként viselkednek – hiszen egymás vetélytársai az élelemért (budget) folytatott harcban.

Ezért a több osztályt érintő feladatok és folyamatok nehezen szoktak menni, és ezáltal kár éri a céget.

Több módszer ismert a silók feltörésére és megszüntetésére, illetve a silók közötti együttműködés erősítésére.

Kérdés persze, hogy ezekre mennyire van szükség.

Ugyanis az informatikai mindig informatika marad, a maga sajátosságaival – a pénzügy pedig pénzügy, a marketing az marketing, és az értékesítés az értékesítés. Ezeket a területeket nem lehet ugyanúgy, ugyanolyan módon, ugyanazokkal a módszerekkel kezelni. Vagy legalábbis az nem lesz tökéletes.

Az egyedi szakterületek – mármint ha jól csinálják – megkövetelik azt, hogy a szakértők gondolkodásmódja idomuljon, a rendszereik az egyedi igényeket és sajátosságokat kielégítsék. Nem lehet ugyanúgy fejleszteni szoftvert egy könyvelő számára, egy marketingesnek, egy értékesítőnek vagy egy mérnöknek. Mindegyik egész mást vár el a programozótól, mindegyik azt akarja, hogy a programozó értse az üzleti igényeket és beszélje az üzleti nyelvet. Nem létezik „univerzális” szoftverfejlesztés.

Akkor miért képeznek az egyetemek „univerzális” szoftverfejlesztőket? Mert lehetetlen lenne minden egyes szakterület egyedi igényei után szaladgálni – és kétséges is lenne, hogy egy specialista kapna-e munkát. Ha szerencséje van és éppen sok munka van a piacon az adott szakterületen, akkor jó sokat kereshetne, ellenben ha éppen nincsen munka valami miatt, akkor értéktelenné válik a tudása.

Ennél már hasznosabb az olyan pályakezdő informatikus, aki még nem specializálódott, de az alapokkal tisztában van, és majd a piaci igényeknek megfelelően specializálódik (felépíti karrierét).

A legeslegjobb viszont az lenne, ha a felsőoktatás érzékenyen követné a piacot, és lehetőséget adna specializálódni – például banki fejlesztőre mindig szükség lesz, mint ahogy telekomos programozóra vagy ipari automatizálásra is.

Kicsit elkalandoztam, vissza a silókhoz!

Hogyan lehet hatékonyan kezelni a silókat informatikai szempontból? Ez attól függ, hogy cég stratégiájában mi az informatika szerepe. De a leggyakoribb megoldás az, amikor az IT a cég szervezeti struktúráját lekövetve specializálódik, azaz minden egyes silóhoz létezik egy informatikai csapat, amelyik az adott siló szoftvereit és igényeit kezeli. Tehát létezik pénzügyi informatikai csapat, marketing informatika, értékesítési informatika, stb.

Mi a közös a búzában és a multinacionális cégben? Hát a siló.