Már régóta minden vállalat működésének alapja az IT. A világ (ma már csak) egyik legnagyobb számítástechnikai vállalata 110 éve létezik, 1911-ben már könyvelésben használt számológépeket gyártottak (az International Business Machines, ugye). Az IT hőskorában megfogalmazódott alapelvek és igazságok még ma is érvényesek, igaz, új megfogalmazásban.
1. A nyílt forráskód is megbízható vállalati használatra
Régi: Még senkit sem rúgtak ki azért, mert neves gyártótól vásárolt
Új: A nyílt forráskód hasonló előnyöket biztosít, mint a neves gyártó
Amikor technológiát vásárlunk, akkor végső soron hosszú távon elkötelezzük magunkat egyik vagy másik gyártó és platform mellett. Ezért cserébe elvárjuk, hogy a szállító is hosszú távon biztosítsa és támogassa az adott hardvert vagy megoldást. Az biztos, hogy még senki sem rúgtak ki azért, mert IBM-től, HP-től netán Oracle-től vásárolt, vagyis a jól bevált gyártók mellett döntött. Mára a nyílt forráskódú megoldások is hasonlóan bizonyítottak, és reális alternatívát jelentenek a nagy gyártók termékeivel szemben. És bármennyire is furcsa, gyakran ugyanezek a régi gyártók biztosítják a nyílt forráskódú megoldásokat is.
2. Béreljük az IT-infrastruktúrát
Régi: Biztonságosan zárjuk el a hardvert egy külön szobába
Új: Ezt a biztonságos szobát akár bérelhetjük is
A vállalatot üzemeltető hardvereket régebben elzárva, egy külön szobában működtették, ahová csak kevesen juthattak be. Az automata naplózással pedig mindig tudhatták, ki járt utoljára a szobában. Ma is szükség van robusztus infrastruktúrára, viszont ez a szoba egy szolgáltatóé is lehet, vagyis nem kell megvásárolni. A magas belépési költségek arra sarkallják főként a kkv-kat, hogy béreljék a számítási kapacitásokat, az IT-infrastruktúrát, az alkalmazásokat, legyen a szolgáltató a közeli adatközpont vagy teljes felhőmegoldás. Az elért megtakarításokat ne zsebeljük rögtön be, egy részét fordítsuk egy alacsony késleltetésű, magas sávszélességű hálózati kapcsolódási pont kiépítésére, és ne feledkezzünk meg a harmadik Neumann-elvről: duplikáljunk mindent.
3. Ismerjük meg a fenyegetettségeket
Régi: Zárjuk le az asztali gépeket, és védjük a vállalat határait
Új: Erősítsük meg eszközeinket, miközben védjük a peremhálózatot is
Az internet korával megszülettek a biztonsági fenyegetettségek. A vállalatok erre lezárták a gépeket, és egyre bonyolultabb tűzfalakkal védték a hálózatuk peremét. A számítógépekbe bezárt felhasználók azonban nem lehetnek kreatívok. Új ötletek innovatív környezetekben, újszerű megközelítések hatására születnek, ennek megteremtésére bizonyos fokú szabadságot kell biztosítani. A két szükséglet közötti egyensúlyt az eszközök biztonsági megerősítése és nem a lezárása jelenti, miközben az otthonokba kitolódott peremhálózatot is biztosítjuk. Ebben a környezetben kollégáink kreativitása kibontakozhat, értéket teremthetnek.
4. A vízesés módszer működhet, eredményeket az agilis módszer hoz
Régi: Informális egyeztetés szükséges az üzleti vezetők és programozók között
Új: informális egyeztetés szükséges üzleti vezetők és programozók között – egy kötelező szabálykönyv szerint
Eredetileg a szoftverfejlesztés a következőképpen zajlott: az üzleti vezető átszaladt a programozóhoz, és megkérdezte, tudsz írni egy programot, amely ezt és ezt csinálja? A programozó gyorsan összedobott valamit, megmutatta az üzleti vezetőnek, majd addig próbálgatták és csiszolgatták, míg jó nem lett. Attól, hogy nem nevezték agilis fejlesztésnek, még az volt, az informális egyeztetések és a sűrű próbálgatások és értékelések eredményesek voltak.
Bonus track: a kapcsolatok ápolása mindenki feladata
A formális vállalati hierarchia idején a CIO feladata volt, hogy a többi vezetővel jó kapcsolatot ápoljon. Akkor tudott sikeresen működni, ha a többi vezető bízott benne. Ilyen egyszerű volt.
Most azonban az IT-csapat bármely tagja kapcsolatba kerülhet a többi részleg bármely tagjával, és ezek a kapcsolatok is befolyásolják az üzlet és az IT viszonyát. Az IT (és a CIO) akkor tud sikeresen működni, ha a vállalat többi része bízik az IT-csapatban. Ha megvan a bizalom, minden könnyebb.
|
Ezután valaki kitalálta a „vízesés” megközelítést, amely működhetett volna, ha az üzleti vezetők pontosak el tudták volna képzelni a teljes működő rendszert, és pontosan le is tudták volna írni. De ez keveseknek sikerült. Majd eljött a scrum, amely az iterációhoz és interakcióhoz épp elég metodológiát tesz, hogy kiölje belőle azt a kevés élvezetet is, amennyit a többi agilis fejlesztési módszernek sikerült megőriznie.
5. Minden az üzleti változásokért van. Vagy mégsem?
Régi: Az IT az üzleti változások fő hajtóereje (ezt megelőzően: Az IT az üzleti változások legnagyobb akadálya...)
Új: Az IT az üzleti változások fő hajtóereje
Amikor a számítógépek még új és modern technológiának számítottak, az üzleti vezetők bíztak bennük, hogy a manuális munkát kiváltva minden téren változást hoznak a folyamatokba, gyorsabban és olcsóbban dolgoznak. Aztán az IT-nek olyan sok, egymáshoz kapcsolódó rendszert kellett támogatnia, hogy ha bármilyen módosítás időrabló, költséges és kockázatos volt. Ezen a vízesés-metodológia sem segített. Most az agilis megközelítéssel, a jobb integrációs eszközökkel és a jó felhasználói élménnyel az IT újból kulcsfontosságú üzleti változásokat generálhat.
6. Az IT azért van, hogy az üzletet támogassa
Régi: A technológia nem a technológia kedvéért van
Új: Az IT vállalja fel a vezető szerepet
Bármennyire is szeretjük a technológiai megoldásokat, egy vállalatnál senki sem engedheti meg, hogy új technológiákat kedvtelésből vezessen be. Másik oldalról ez nem azt jelenti, hogy az IT szerepköre az üzleti utasítások végrehajtásával bezárul. Az IT-nek technológiai vezető szerepet kell felvállalnia. A gyakorlatban ez azt jelenti, hogy az IT támogatja azokat a felhasználókat, akik saját technológiát szeretnének fejleszteni vagy vásárolni, például azzal, hogy megmutatja milyen biztonságosabb vagy olcsóbb alternatívák vannak a piacon. Nem kell csírájában megfojtani minden kezdeményezést, csak azért, mert a fejlesztés ötlete nem az IT-osztályról származik.