A B2B CRM rendszerek azoknak a társaságoknak készülnek, akik élő kereskedőkkel dolgozzák meg a céges érdeklődőiket. Ezek az eladási folyamatok ugyan nagy értékűek, de szerencsétlenül hosszúak, és teljesen kiszámíthatatlanok. Bármi bármikor megtörténhet, bármilyen irányba fordulhatnak a dolgok. Sőt. Teljesen más sales metódust használnak azok a társaságok, akik ipari műszereket adnak el, mint azok, akik szeszesitallal, vagy informatikai rendszerekkel foglalkoznak. Ami az egyik helyen magától értetődő, arról máshol még csak nem is hallottak. Opteamust ezért terveztük eleve rugalmasnak, és minden de minden testreszabható benne. Az új funkciókat is egy-egy konkrét igény alapján, de univerzálisan alkalmazhatóan tervezzük meg. Néha fordul csak elő, hogy azzal a feltételezéssel élünk, hogy “ez mindenhol így lesz jó”, és ebben a néhány esetben is rendre kiderül, hogy dehogy 😦 Minden de minden, mindenhol egyedi. Szóval: hiába gondoltuk, hogy mindenhol jó lesz, ha egy adatlap nem nyúlik le egy méter hosszan a képernyőről, és legyen konfigurálható, mely mezőket rejtsünk a háttérbe. Persze, hogy kiderült: vannak akiknek a teljes, hosszú kijelzés a favoritjuk. Szóval mostantól EZ IS adattípusonként beállítható…
Santorinin kezdődött
Ez a történet Santorinin kezdődött. Tudod, ez az a kis görög sziget, ahol az ablakokat és a bútorokat kékre festik. Minden görögországi prospektus ezekkel a képekkel reklámozza magát, de ez valójában csak ennek a szigetnek a sajátja. Máris elkanyarodtam… Szóval minden nyaralásra elviszek magammal egy könyvet, amiről azt gondolom, érdemes tiszta fejjel elolvasnom. Ezen a nyáron Bill Gates könyvét vittem magammal, az volt a címe, hogy “Üzlet @ gondolat sebességével”. Világéletemben Oracle rendszerekkel dolgoztam, nagyon kíváncsi voltam, mit tud mondani Larry halálos ellenfele a másik oldalról. A könyv arról a triviális felismerésről szólt, hogy immáron a számítógépek és adatbázisaik összeköthetőek, és készíthetőek olyan rendszerek, amelyek egy válallat minden részéről elérhetőek. Hát ez nem volt már akkor sem valami forradalmi gondolat, pláne nem úgy, hogy Gates olyan példákat tett mellé, hogy náluk a Microsoftnál már az új dolgozók jelentkezését és az irodaszerek vételezését is ilyen “forradalmi” módszerekkel oldják meg. “Drótozd be a vállalatod” – sulykolta a szerző, amivel viszont elgondolkoztatott…
Bővebben: “Santorinin kezdődött”
QR kód az épületekben?
Ugyan már! Melyik az a magyar cég, aki német precizitással felcímkézné az épületeiben lévő helységeket és berendezéseket, csak azért, hogy a karbantartók nagy néha lecsippanthassák azokat, amikor valamilyen problémát észlelnek? A karbantartók QR kód nélkül is ki tudják választani egy űrlapon az általuk jól ismert berendezéseket, ehhez nincs szükség ekkora felhajtásra. Általában valóban ez a helyzet. Vannak viszont olyan, nem tipikus helyszínek, amikor a QR kódnak tényleg van praktikuma.
Gyakori munkavégzés
Rögtön más a helyzet, ha a karbantartóknak nem “nagy néha”, hanem hetente, vagy akár naponta kell foglalkozniuk a berendezésekkel. Egy erőműben vagy gyárban naponta kell ellenőrizni a kritikus műszaki eszközöket, de egy irodaház takarításánál is, a takarítóknak naponta kell bejárniuk ugyanazokat a helységeket. Minél többször van szükség egy berendezés vagy helyiség azonosítására, annál inkább érdemes megfontolni a QR kód használatát, amivel némi időt nyerhetünk, és persze elkerülhetjük a manuális választásból adódó hibákat.
Túl sok eszköz
Vannak különleges helyszínek, ahol olyan magas az eszközök száma, hogy még a rutinos karbantartók sem tudják megmondani, a folyosón egymás mellett lévő 5 vészkijárati lámpának, 3 videokamerának és 3 hangszórónak mi is a pontos jele. Ilyenkor nagy könnyebbség, ha elég lecsippantani a problémás berendezést, és nem kell kiválasztani a nevét, akár több ezer másik hasonló berendezés közül.
Ahogy már írtuk, Nincsenek szabályok, minden az arányokon és a számosságon múlik. Vannak helyszínek, ahol javasoljuk a QR kód használatot, és vannak helyszínek, ahol éppen hogy figyelmeztetünk azok hasztalanságára. Mindenesetre, Opteamus CAFM rendszerünk igény szerint készen áll erre is.
Paranoia
Amikor Opteamus rendszerünket terveztük, még gyerekcipőben jártak a felhő alapú vállalati rendszerek, így róluk nemigen vehettünk példát. Létezett viszont a legendásan elmebeteg és maximálisan vicces Paranoia nevű szerepjáték, aminek cyberpunk jellegű világa megihletett minket. A jövőbeli Alpha Complex kolónián egy paranoiás zsarnok mesterséges intelligencia irányítja az életet, ahol a belbiztonsági erők, titkos társaságok, és szabadúszó vagányok, a troubleshooterek törnek folyamatosan egymás életére, változatosan és tragikomikusan.
A játékban a totális diktátor Friend Computer klasszikus sávos biztonsági rendszert használt az adatainak védelmére, amelyek a szívárvány színei alapján voltak elnevezve, úgymint Infrared, Red, Orange, Yellow, Green, Blue, Indigo, Violet, és Ultraviolet. Az Alpha Complexben nem csak az adatok, de minden, az élelemtől kezdve az utcákig minden fel volt címkézve ezek valamelyikével, és mindenhez csak a jogosult lakók férhettek hozzá. Az Opteamus prototípusában pontosan ilyen sávos biztonsági rendszert használtunk és még a titokszintek neveit is megtartottuk. Mára persze elhagytuk a színkódokat, és inkább beszélő neveket használunk, mint a publikus, kereskedő, igazgató, admin. Mostani biztonsági rendszerünk sem egyszerűen sávos, hanem jóval szofisztikáltabb, de alapvető szigorúságunk a Paranoia mindenható zsarnok mesterséges intelligenciájával vetekszik 🙂
Opti minden rendszerüzenetet harcos csatakiáltással zár. A kis felugró ablakban eredetileg “A számítógép a barátod” szöveg szerepelt, ami szintén Friend Computer gyakran ismételt, megnyugtatónak szánt propaganda szólama volt. Felhasználói nyomásra ezt később a sokkal komolyabb és hazafiasabb “Hass alkoss gyarapíts” jelmondatra cseréltük – na erre már nem érkezett komolytalansági kifogás 🙂 Egyes ügyfelek persze saját hatáskörben ezt is megváltoztatták, hol a kilúgozott “Köszönöm“-re, hol a kifejezetten mókás “A vár feladásáról szót nem ejtünk” üzenetre, ez utóbbi ugye a Dobó István-féle esküből vett idézet.
A mai napig alapértelmezett hibaüzenetünk a “A felelőtlenség árulás. Jelentsd azonnal!” ami szintén a Paranoia világára utal. Friend Computer a legkisebb hibában is árulók keze munkáját sejtette, és folyamatosan törekedett azok felkutatására, majd likvidálására. Nyilván ezt a szöveget is ki-ki lecseréli egy semlegesebb másik mondatra, mint a tipikus “Hiba történt, kérjük jelezze a helpdesknek!“.
Engem a mai napig mosolygásra késztetnek ezek az apróságok, de ügyfeleinknek nem kötelező velem mosolyognia, mert mindez nincsen kőbe vésve. Opteamus rendszerünkben szinte minden testreszabható. Aki akarja annak katonásan szigorú Opteamust konfigurálunk, aki akarja, az a végletekig szabad rendszert kap tőlünk. A feliratokat pedig minden ügyfelünk kedve és szervezeti kultúrája szerint írhatja át. A számítógép a barátod 😀
Nincsenek szabályok
Azt hinnénk, hogy a számítástechnika egzakt mérnöki tudomány. Egyértelmű műszaki technikai szabályok alapján kell meghozni a tervezési és kivitelezési döntéseket, aminek az eredménye kiváló szoftvertermék. Az egyes helyzetekre léteznek vitán felül álló, bevált megoldások, amik megtanulhatóak, és szisztematikusan alkalmazandóak. Bárcsak így lenne!
A valóságban a számítástechnikai rendszerek tervezése sokkal inkább művészet, ahol a tervezőnek az intuíciója, tehetsége és tapasztalata alapján kell mérlegelnie az adott szituáció finom részleteit is. Vegyünk egy példát: tervezzünk egy űrlapot, amin az irodaházak bérlői be tudják jelenteni a problémáikat a gondnokság felé. Ezen az űrlapon meg kellene adni a probléma minél pontosabb helyét is, hogy a karbantartó szerelők odataláljanak. Vajon melyik megoldás lenne az igazi az alábbi kettő közül?
A-megoldás: a bejelentő kötelezően válassza ki a felbukkanó értéklistából az ingatlant, épületszárnyat, emeletet és szobaszámot. Mérnöki szemmel ez lenne a precíz, valóságot legjobban lekövető megoldás. A karbantartók pontosan tudnák, hova kell menniük, és rendszer szinten is helyiség pontosságú statisztikákat lehetne készíteni a bejelentésekről. Csakhogy nem ez az egyetlen, de még csak nem is ez a legfontosabb tervezési szempontunk. Egy ilyen képernyő hármas terhet ró a felhasználókra minden alkalommal, amikor bejelentenek – e miatt utálkozni fognak. További gond, hogy az üzemeltető cég adminisztrátorainak folyamatosan naprakészen kell tartaniuk az épületek, emeletek, helyiségek nyilvántartását, ami több tucat vagy száz ingatlan esetében nem egyszerű feladat. A precizitás árát ez esetben igen komoly adminisztrációs munkával kell megfizetnünk:
B-megoldás: a bejelentő az ingatlan kiválasztása után egyetlen szabad szöveges mezőbe írja bele, hová várja a szerelőket. Első látásra primitív megoldásnak tűnik, de a felhasználók imádni fogják a csodásan egyszerű űrlapot. Az adminisztratív teher szinte zéró, ami azt is jelenti, hogy szinte azonnal be lehet majd vonni a rendszerbe egy-egy új ingatlant. Az adataink természetesen meglehetősen pontatlanok lesznek, nem tudunk helyiség szintű statisztikákat készíteni – de meglehet, hogy ilyenre senkinek nincs is szüksége. Ha a helyszínt jól ismerő technikusaink vannak, akkor ez teljesen működőképes megoldás lesz:
A részletek mérlegelése nélkül nem mondható ki, hogy egyik megoldás jobb lenne, mint a másik. Tudnunk kell, mi is az üzleti célja a rendszernek: a bérlőknek akarunk kényelmi funkciót adni, az üzemeltetőknek készítjük a rendszert vagy a menedzsment bízott meg minket, mert átláthatóbb működést szeretnének? A hatékonyság fokozása a fontosabb, vagy a dokumentáltság szintjét kell növelni? Sok vagy kevés épületről és helyiségről van szó? A bejelentők a problémásabbak vagy a helyszínre kiszálló technikusok? Egy jó tervezőnek a célokat, arányokat és a hangsúlyokat figyelembe véve kell döntést hoznia, cseppet sem gépiesen, hanem finom intuitív módon.
Művészek, akik vagyunk 😉
Még gyorsabban keresni
Ha a nyomozók meg akarják találni azt a gyanúsítottat, aki az Andrássy út 14-ben lakik ÉS drogot rejteget a lakásában, akkor számunkra nyilvánvaló, hogy mit tesznek. ELŐSZÖR elmennek az Andrássy út 14-be, AZUTÁN házkutatást tartanak az ottani összes lakásban, drogok után keresve. Ha ugyanezt a feladatot egy számítógépre bíznánk, könnyen lehet, hogy azt javasolná, ELŐSZÖR tartsunk házkutatást Magyarország összes lakásában, és AZUTÁN a találatok közül válogassuk ki az Andrássy út 14-beli lakókat. A számítógépnek ugyanis ebben az esetben ez a két keresési feltétel teljesen egyenrangú, és a kiértékelés sorrendje tetszőleges. A valóságban viszont jól tudjuk, hogy egy házkutatás rettentő időigényes, ugyanakkor az Andrássy út 14-et megtalálni nagyon könnyű, így nagyon nem mindegy, melyik keresési feltétellel kezdünk.
Ha egy számítógépes adatbázisból lassan kapunk választ, jó eséllyel effajta probléma van a háttérben. A programozó, (vagy maga az adatbázis) logikus, de a gyakorlatban mégis szerencsétlen stratégiát választott egy kérdés megválaszolására.
Aktuális fejlesztésünk arra a speciális esetre fókuszált, ahol egy tudhatóan nehézkesebb művelettel kell óvatosan bánni: a számított mezőkkel. Ezek a műveletek értelemszerűen lassabbak, mint a többiek: nyilván tovább tart kiszámolni, pl. egy céghez tartozó projektek profitjának összegét, mint elővenni egy cég adószámát az adatlapjáról. Ezt tudva, mostantól félreérthetetlenül úgy kérdezünk le az adatbázisból, hogy minden lehetséges szűkítést elvégzünk, mielőtt egy ilyen nehéz műveletre sor kerülne. Példának okáért, ha valaki lekérdezi a Lashoo and Ross cégnek kiállított kiegyenlítetlen számlákat, akkor felismerjük, hogy a számla kiegyenlítetlenségét megvizsgálni roppant költséges (mert számított mező van mögötte). E miatt úgy fogalmazzuk meg a vonatkozó kérdést az adatbázis felé, hogy az mindenképpen a gyorsabb vizsgálattal kezdjen, először válogassa le a Lashoo and Ross számláit, és már csak azoknak vizsgálja meg a kiegyenlítettségét. Ennek az eredménye minden olyan Opteamus képernyőn jótékonyan érződni fog, amelyek számított mezőkkel dolgoznak. Ilyenek a property management terület kijövő és bejövő számlái, vagy a helpdesk terület bejelentéseinek sla értékei.
Jó érzés ehhez hasonló feladatokon dolgozni. Ezek ugyanis olyan szituációk, amelyek csak olyan nagy rekordszámú és nagy bonyolultságú helyzetekben válnak láthatóvá, amelyekkel a kkv szektorra célzó garázs-szoftverek soha nem találkoznak. Büszkék vagyunk rá, hogy mi igen, és hogy Opteamus ipari szinten áll ügyfelei rendelkezésére.
Zöldmezős munka
Irigykedem az autómérnökökre. Ők is komoly kihívásokkal néznek szembe, de előbb utóbb csak kiokumlálják, milyen legyen az új modell. A gyár legyártja, a vevők tolonganak érte, mindenki örül. Ahogy telik múlik az idő, és új igények fogalmazódnak meg, hát újrakezdik az egészet. Új tervek, új gyártás. A régi autók mennek a roncstelepre, az új autókat boldogan röffentik be a vevőik. Mi úgy hívjuk ezt: zöldmezős munka. Tudjuk, hogy mit kell megcsinálni, és szép nyugodtan megcsináljuk.
Irigylem őket, mert hozzájuk senki fordul azzal, hogy: lécci alakítsd át a mostani(!) autómat, mert mától szükségem lenne arra, hogy az alsó rész vízálló, a felső rész pedig golyóálló legyen, és a kerekekbe menet közben lehessen levegőt fújni, hogy egy golyó ütötte defekt ne állítsa még a gépet. Ilyen autót természetesen meg lehet tervezni, le is lehet gyártani. Nade egy LÉTEZŐ AUTÓT ilyen módon átalakítani???
Tőlünk, IT mérnököktől sajnos rendre ezt kérik. És igaz, hogy a szoftver kódja könnyebben alakítható, mint az autó matériája, de nem ez az igazi nehézség itt. Egy komplex rendszerben minden kapcsolódik mindenhez. Egyetlen apró változtatás a kapcsolódások mentén újabb és újabb változásokat vált ki, amelyek nagyon nehezen felmérhetőek és amelyek nagyon komolyan veszélyeztethetik a rendszer működését. Természetesen ezzel tisztában vagyunk, és eleve olyan rendszereket tervezünk, ami valamilyen szinten fel van készülve a módosításokra. Feltételezünk bizonyos fajta jövőbeli igényeket, és úgy strukturáljuk a rendszert, hogy ezeken a területeken minimális felfordulást okozzon egy-egy változtatás. Számítunk arra, hogy egy cégnek megváltozik a neve. Számítunk arra, hogy egy cég több apró cégre oszlik. Még arra is számítunk, hogy holnaptól forint helyett euróban számolunk, vagy a kínai abc-vel kell működnünk. De nyilván minden szál hajunkat kitépnénk, ha hirtelen tizenkettes számrendszerben kellene minden számértéket megjeleníteni, vagy mostantól törvény mondaná ki, hogy megszűnik az elipszilonos ly.
Mi, IT mérnökök, nap mint nap a lehetetlent kísértjük.
Szívesen.
Hasznos vagy haszontalan?
Ha megkérdezünk egy fiatal felnőttet, hogy milyen párt szeretne magának, jellemzően olyanokat fogunk hallani tőle, hogy szőkét, magasat, vékony derekút, kék szeműt, olyat aki tudja utánozni a patak csobogását, aki tud tiramisut csinálni és így tovább. Akinek még fogalma sincsen egy valóságos párkapcsolatról, az jellemzően ilyen szempontrendszer alapján keres. Ha ugyanezt a kérdést tapasztaltabb korosztálynak tesszük fel, akkor sokkal praktikusabb választ kapunk. Aki tudja, mi fán terem az együttélés, az nem az effajta részleteket, hanem a lényeget tartja szem előtt: olyan társat keres, aki kedves, akinek van stílusa, de legfőképpen olyat, aki passzol hozzá.
Egy szoftver kiválasztása nagyon hasonlít a párválasztáshoz. Aki még soha nem használt pl. CAFM Facility Management szoftvert, az gyakran elvész a lényegtelen részletekben. Ha nem is egy patak csobogásának hangját várják el, de a legfontosabb kívánalmak listájában szerepeltetik, hogy az irodák padlójának anyagát is tartsa nyilván a rendszer. Akik már használtak effajta szoftvert, azok pontosan tudják, hogy nem ez a lényeg. A szoftvernek nem okoz gondot száz ingatlan ezer szobájának műszaki állapotát és tízezer apróságból álló komplett leltárát nyilvántartani. Képes rá. De vajon hány munkatárs hány munkaórája kell majd ahhoz, hogy ez a nyilvántartás naprakész legyen? Ijesztően sok, ahhoz képest, hogy mennyi ennek az egész munkának a haszna.
Tapasztalatlan érdeklődőként még minden funkció egyformán izgalmasnak tűnik, de a gyakorlati hasznukat tekintve óriási különbség van közöttük. Vannak funkciók, amelyek egyszerűen életképtelenek a magyar viszonyok közt. Vannak amelyeknek életszerűtlenül magas az adminisztrációs ára, míg másoknak csekély munka befektetésével is kiugróan magas a hozadéka. A szabad piacon működő cégek legfontosabb célja a hatékonyság – korlátozott számú munkatársnak kell minél több helyszínt menedzselnie. Egy szoftver ebben nem az adminisztráció fokozásával segít, hanem a kötelezően elvégzendő elszámolások, kalkulációk minél gyorsabb, minél pontosabb és lehetőleg automatikus elvégzésével. Egy CAFM rendszernek természetesen tudni kell mindent adminisztrálni, de valódi ereje a szokásos napi munkafolyamatok felgyorsítása. A pénzügy, a backoffice területén egy jó szoftver komoly munkaidő megtakarítást hoz – ráadásul drasztikusan csökkenti az emberi hibákat is. Például, ha a bejövő számlák Opteamusban vannak, nem kell hosszasan keresgélni, hol az eredeti papír, kinél áll a jóváhagyás, mi lett a számla sorsa. Nagy könnyebbség lehet az is, ha egy havi számlázásnál nem egyenként kell minden bérlő szerződéseit megtalálni, ha nem kell bérlőnként másik euró árfolyamot kikeresni, ha nem kell figyelni arra, hogy minden háznál más szisztéma szerint osztjuk el a közös közmű költségeket. Ha a szoftver ezeket pár gombnyomásra precízen kikalkulálja, az már határozott versenyelőny minden versenytárssal szemben, akinek a szoftvere nem képes ugyanerre.
Több mint húsz év tapasztalatával nem csak abban segítünk, hogy Opteamus rendszerünkkel mindent le lehessen adminisztrálni, de abban is, hogy valóban hatékonyabbá tegyük a szervezet munkáját.
Távolról is ügyesen
Régebben is csináltunk távolról bemutatókat, de meglehetősen mérsékelt sikerrel. Az utóbbi időben azonban minden megváltozott. Az érdeklődő cégeknek már sokkal menőbb, sokkal nagyobb képernyőik vannak a konferenciatermeikben, amin követni tudják a műsorunkat. Azt is mindenki megszokta, hogy nincs mellette a tárgyalópartnere, így sokkal inkább a mondanivalóra kell koncentrálnia a gesztusok helyett. Úgy tűnik én is megszoktam ezt a helyzetet, mert egymás után nyerjük meg az olyan munkákat, ahol mind az ismerkedés, mind a szerződéskötés, mind a bevezetési munka, sőt a felhasználói oktatás is teljesen távolról történt.
Technikai bravúr ez a javából, és nem az egyetlen. A bevezetést követően ügyfeleink is átszervezhetik az életüket, hogy Opteamust ne csak az irodából, de akár otthonról, vagy terepről is használják. Opteamus mióta világ a világ, mobil rendszer. Az utóbbi években sokat dolgoztunk azon, hogy tetszőleges mobil eszköz tetszőlegesen apró képernyőjén is fokozzuk a használhatóságot, és nem hiába. Opteamust használni mobil helyzetekben, az bizony versenyelőny: Rugalmas CAFM software: OPTEAMUS (fm-szoftver.hu)
Koronavírus ide vagy oda
Nem, nem voltunk felkészülve a járványra. De anno tudatosan olyan iparágat választottunk, amelyik kevéssé van kitéve a fizikális világnak. Olyan terméket állítunk elő, amelyhez nem kell alapanyagot beszerezni, nem kell raktározni, amelynek értékesítéséhez és beüzemeléséhez minimális élőerő is elegendő, akár fizikai kapcsolat nélkül is. Az idei üzletmenetünket nem is viselte meg a koronavírus, sőt.
Sok ügyfelünk, a karantén okozta üresjáratot arra használta fel, hogy átgondolja jelenlegi folyamatait, és racionalizálja azokat. Számos új, izgalmas megbízást kaptunk tőlük, a tableten aláírható munkalapoktól kezdve a dinamikusan változó űrlapokon keresztül az elektronikus számlázásig, amelyeket alig győztünk megvalósítani. (A jövő évi fejlesztési naptárunk is hónapokkal előre tele van.) Mindennek eredményeképpen, mostanra olyan funkciókészlettel rendelkezünk, amivel Opteamus gyakorlatilag ügyviteli rendszerként képes működni egy kis-közepes méretű cégnél.
Bizakodva kívánunk boldog karácsonyt és eredményes Új Évet mindnyájunknak!
Még magasabbra
Úgy kell ezt elképzeli, mint amikor az ovisok fakockákból tornyot építenek. Az elején nagyon könnyű dolguk van, hiszen két építőkocka könnyen egymásra helyezhető. Erre vannak tervezve. A tizedik emelet után viszont a torony magassága és az ebből adódó labilitása igen komoly (és exponenciálisan nehezedő) kihívást fog jelenteni a bátor kis mérnöknek.
Opteamus rendszerünket kifejezetten úgy terveztük, hogy könnyen módosítható legyen. Olyan ügyféligények, amelyek máshol napokig tartó “modulfejlesztéssel” készülnek el, nálunk tízpercek alatt megvalósulnak. Egy új bevezetést általában nagyon gyorsan meg is tudunk csinálni, az ügyféligényeket maximálisan figyelembe véve. Mindenki boldog is az eredménnyel.
Opteamus ugyanakkor nem csupán egy egyszerű cetlizős CRM vagy ticketező szoftver, ügyfeleink többsége gyakorlatilag vállalatirányítási rendszert építtet velünk. Tipikusan olyanokat, ahol a céges adatok bonyolult folyamatokkal, speciális üzleti és elszámolási szabályokkal, fillérre pontosan egészen a számlázásig eljutnak. Egy ilyen nagy komplexitású CAFM vagy Service Management jellegű Opteamusban mindig kihívás egy továbbfejlesztés kivitelezése. Ahogy az egyre magasabb kockatorony egyre komolyabb statikus problémákat jelent, úgy az egyre összetettebb szoftver-rendszer is egyre nehezebben átlátható tervezési és megvalósítási problémákat vet fel. Milyen jó is lenne hátradőlni, kinyitni egy sört, és elégedetten szemlélni, milyen szépen működnek a felépített rendszereink. Igazán kár, hogy az üzlet mindig változik, és nekünk újra és újra a maximumot kell nyújtanunk, mert ha a kockatorony össze is dőlhet, Opteamusunk esetében ez nem opció…
Ugyanolyat kérek!
Képzeld el, hogy bemész a BMW szalonba, és azt mondod: “Kérem szépen azt a dögös M3-ast, de az ülés kárpitjának ugyanolyan mintát kérek, mint amilyen a kedvenc Louis Vuitton hátizsákomnak van!” Vajon mit érezhet ilyenkor az eladó?
Nos, ugyanazt, amit mi is, amikor az kérik tőlünk, hogy “Láttunk egy szoftvert, ami meg tudja mérni a felhasználó lázát. Bele tudnátok ezt fejleszteni Opteamusba?”
Szövet – szövet, szoftver – szoftver, akkor miért is nem működik mindez olyan magától értetődően? Mind a BMW, mind mi az Alpha, és minden más gyártó cég is használ egyfajta gyártástechnológiát (gépeket, eszközöket), és valamifajta alapanyagokat (szövetet, alkatrészt, programmodulokat) amelyeket a beszállítóitól vételez. Ha a legyártandó terméken bármilyen módosításra van szükség, az csak akkor lehetséges, ha a beszállító tud szállítani megfelelő új alkatrészeket és a gyártósort át lehet állítani ezek fogadására. Ez sok esetben lehetséges, számos különböző opcionális kárpitból lehet választani az M3-ba, de olyat nem, amire a gyártás nincs felkészülve. Majd, ha a beszállító LV mintás szövetet tud szállítani, abban a pillanatban lehet módosítani a gyártási folyamaton. Egy szoftverbe is sok újdonságot bele lehet tenni, de olyat nem, amihez nincsen meg az alapvető infrastruktúránk, esetünkben nincsen olyan programkomponensünk, ami hőmérsékleti adatokat tudna szolgáltatni Opteamusnak. Majd, ha a böngészők szoftvere képes lesz hőmérséklet adatokat szolgáltatni a felhasználóról, abban a pillanatban azt tudjuk majd kezelni Opteamusban.