Egyedi Webalkalmazás Vagy Dobozos SaaS

Szinte egyetlen egyedi webalkalmazás fejlesztés sem specifikációval kezdődik. Egy táblázattal kezdődik, amelyet valaki azért készített, hogy egyetlen dolgot kövessen, aztán kapott egy második oszlopot, majd egy fület, majd egy képletet, amelyet csak egyetlen ember ért. Három évvel később az a fájl tartalmazza a beosztást, az árakat és az ügyféladatok felét, négyen szerkesztik egyszerre, és senki sem tudja biztosan megmondani, melyik példány az érvényes.

Ez az igazi döntési pont, és nem ez az, amelyet a legtöbb építeni vagy venni témájú cikk tárgyal. Nem üres lap és termék között választanak. Három kiút közül választanak egy működő, de törékeny folyamatból: megvenni egy terméket, összerakni valamit egy no-code platformon, vagy olyan szoftvert rendelni, amely a saját munkamódjukra van szabva.

Egyedi webalkalmazást építsen vagy SaaS-t vegyen? Vegyen, kivéve ha a három feltételből legalább kettő teljesül: a folyamat versenyelőny és nem rezsi, egyetlen termék sem illeszkedik hozzá anélkül, hogy eltorzítaná a munkamódját, és az integrációs munka teszi ki a feladat nagyobb részét. Ha csak egy teljesül, a termék plusz konfigurálás szinte mindig olcsóbb. Az egyedi fejlesztés emellett folyamatos költségküszöbbel jár, amely évente nagyjából az építési ár 15-20 százaléka, mindaddig, amíg a rendszer él.

A táblázat, amely teherhordóvá vált

A minta elég konkrét ahhoz, hogy nevet kapjon, és a csapatok általában éppen a megnevezésétől ismernek magukra.

Egy emberrel és egy céllal indul. Valakinek tudnia kell, mely munkák vannak lefoglalva a héten, ezért megnyit egy táblázatot. Egy második embernek olvasnia kell, ezért átkerül egy közös meghajtóra. Aztán egy harmadiknak szerkesztenie kell, így már többen gépelnek ugyanabba a cellába egyszerre. Aztán jön havonta egy fül. Aztán egy keresés egy második fájlban. Aztán egy makró, amelyet egy azóta távozott külsős írt.

Az árulkodó jelek mindig ugyanazok. A fájl nevében dátum és verziószám van. Van egy fő példány, és mindenki tudja, ki őrzi. Az új belépő betanítása azt jelenti, hogy megmutatják neki a fájlt, ahelyett hogy elmondanák a folyamatot, mert a folyamat sehol máshol nincs leírva.

Ezen a ponton a táblázat már nem dokumentum. Olyan alkalmazás, amelyben nincs hozzáférés-szabályozás, nincs naplózás, nincs érvényesítés, nincs védhető mentési szabály, és egyetlen karbantartója van. Működik, épp ezért nem cserélte le senki, és épp ezért drága most lecserélni.

Mennyibe kerül valójában a jelenlegi állapot

A táblázatot senki nem számszerűsíti, ezért ingyenesnek látszik. Nem az, és a számítás bárki saját cégére könnyen elvégezhető.

Kezdjük az újragépeléssel. Ha két ember naponta fejenként 45 percet tölt azzal, hogy adatokat mozgat a táblázat, a könyvelőprogram és egy közös postafiók között, az heti hét és fél óra, vagyis nagyjából 340 óra egy negyvenöt hetes munkaévben. Teljes költségen számolt GBP 22 órabérrel ez évente körülbelül GBP 7 500 arra, hogy számokat másoljanak egyik képernyőről a másikra, és ez semmit nem vesz meg azon kívül, hogy elgépelhessék.

Jön ezután az egyeztetés, amikor valaki havonta összeveti a táblázatot a hiteles forrással, és fél napot tölt annak eldöntésével, melyik változatnak van igaza. Jönnek a későn észrevett hibák: a múlt havi áron kiküldött ajánlat, a kétszer lefoglalt munka, az elmulasztott megújítás. Mindegyik kis összeg és egy bosszús ügyfél, és egyik sem jelenik meg semmilyen költségvetési soron.

Jön végül a kulcsember-kockázat. Egyetlen ember érti a képleteket, és amikor ez az ember beteg, szabadságon van vagy elment, a folyamat találgatássá silányul.

A táblázatban tárolt személyes adat is szabályozott adat

Ha a fájl neveket, elérhetőségeket, munkaügyi nyilvántartást vagy ügyféladatokat tartalmaz, az személyes adat, és a UK GDPR ugyanúgy vonatkozik rá, mint egy adatbázisra.

Az ICO egyértelműen fogalmaz arról, mit követel ez. Az adatbiztonsági útmutatója kimondja, hogy a UK GDPR egyik alapelve a személyes adatok biztonságos kezelése megfelelő technikai és szervezési intézkedésekkel, és hogy ezeknek az intézkedéseknek biztosítaniuk kell a rendszerek és a bennük kezelt személyes adatok bizalmasságát, sértetlenségét és rendelkezésre állását. Egy laptopon lévő táblázatban nincs soronkénti jogosultság, nincs megőrzési szabály, és nincs nyoma annak, ki mit olvasott, ráadásul teljes egészében sokszorozódik minden alkalommal, amikor valaki elküldi levélben.

A következmények nem elméletiek. Az ICO 2024 októberében GBP 750 000 bírságot szabott ki a Police Service of Northern Ireland-re, miután egy közérdekű adatigénylésre kiadott táblázat rejtett adatai felfedték mind a 9 483 PSNI-tiszt és -alkalmazott vezetéknevét, kezdőbetűit, rendfokozatát és beosztását. A határozat az 5(1)(f), a 32(1) és a 32(2) cikkre hivatkozik. Az ICO közszférára alkalmazott megközelítése nélkül a bírság GBP 5,6 millió lett volna.

Minden szervezetnek, amely táblázatokon futtat egy folyamatot, van valahol egy ilyen munkalapja.

Vegye meg a terméket: amikor a SaaS nyilvánvalóan helyes

Az esetek többségében ez a válasz, és megérdemli, hogy elsőként érveljünk mellette, ne pedig egy záró bekezdésben intézzük el.

Ha a folyamata általános, a termék létezik, és olcsóbb bárminél, amit építeni tudna. Bérszámfejtés, költségelszámolás, ügyfélszolgálati jegykezelés, időpontfoglalás, elektronikus aláírás, könyvelés, jelentkezőkövetés. Valaki egy évtizedet és egy nagy fejlesztőcsapatot fordított azokra a szélső esetekre, amelyekkel ön még nem találkozott: a szökőév hibájára, az áfakulcs változására, a periódus zárása után érkező visszatérítésre.

Emellett olyan munkát vásárol, amelyet különben megfizetne. A szállító viszi a rendelkezésre állást, a biztonsági javítást, a böngészők változását, az akadálymentesítést és azokat a megfelelőségi bizonyítékokat, amelyeket az ügyfelei kérnek. Ezek egyike sem jelenik meg funkcióként, és mindegyik valódi pénz.

Az őszinte teszt nem az, hogy a termék mindent tud-e. Az, hogy elvégzi-e azt a fontos 80 százalékot anélkül, hogy bármi olyat meg kellene változtatnia, ami számít önnek. Ha az egyetlen eltérés az, hogy a csapata munkát mond, a szoftver pedig jegyet, vegye meg a szoftvert, és változtassa meg a szót.

A három feltétel, amely indokolja az egyedi webalkalmazás fejlesztést

Az egyedi fejlesztést stratégia indokolja, nem bosszúság. Három feltétel van, amely valóban alátámasztja, és a használható szabály az, hogy legalább kettőre szükség van közülük. Egyetlen feltétel önmagában szinte mindig olcsóbban megoldható termékkel és konfigurálással. Ugyanez a teszt érvényes nagyvállalati léptékben is, amit a CRM és ERP építeni vagy venni útmutatónk egy másik nagyságrendben tárgyal.

A folyamat megkülönböztető erő, nem rezsi

Kérdezze meg, mit venne észre egy ügyfél, ha a folyamat kétszer olyan jó lenne. Ha a válasz az, hogy semmit, akkor rezsi, és meg kell venni, mert a kiváló bérszámfejtéstől nem lesz több megrendelése. De az a szakosodott kivitelező, amelynek beosztási logikája minden furgon napjából kisajtol még egy munkát, vagy az a hitelező, amelynek bírálati szabályai maguk a termék, versenyelőnyt vezet át azon a szoftveren. Nem lehet olyan előnyt venni, amelyet a versenytársai ugyanazon a havidíjon megvehetnek.

Egyetlen termék sem illeszkedik a folyamat torzítása nélkül

Minden termék feltételezéseket kódol arról, hogyan folyik a munka, és annak jele, hogy ezek önnél hibásak, az, hogy a bevezetéshez fel kellene hagynia valami jövedelmezővel. Ha a cége olyan alapon árazik, amelyet a termék nem tud kifejezni, és éppen ez az árazás miatt választják önt az ügyfelek, akkor a termék azt kéri, hogy váljon átlagosabbá egy licencdíj fejében.

Az integrációs felület az igazi munka

Néha az érdekes rész egyáltalán nem a képernyőkben van. Abban van, hogy az egyik rendszerből készletet, a másodikból árat, a harmadikból szerelői szabad kapacitást húz le, az eredményt pedig egy negyedikbe írja. Amikor a ráfordítás nagyobb része integráció, a felhasználói felület csak vékony réteg a saját csővezetéke fölött, és a termék beépített képernyőire van a legkevésbé szüksége. Ezt a feltételt becsülik alá a leggyakrabban, és itt lakik a középső csapda.

A középső csapda: megveszed, aztán mégis megépíted

A legdrágább kimenetel az, ha egyik utat sem járják végig tisztán. Vagyis megvesznek egy terméket, mert olcsóbbnak látszott, aztán többet költenek arra, hogy a folyamathoz hajlítsák, mint amennyibe egy egyedi fejlesztés került volna, és közben fizetik a licencet is.

Fokozatosan történik, és külön-külön minden lépés védhető. A termék nem illeszkedik, ezért bevonnak egy bevezetési partnert. A partner a szállító saját szkriptnyelvén ír konfigurációt, ami kód, csak nem tűnik kódnak, mert a terméken belül él. Aztán beszélnie kell két másik rendszerrel, ezért vesznek egy integrációs platformot. Aztán a szállító kiad egy főverziót, és a testreszabásokat regressziósan tesztelni kell.

Ezen a ponton az egyedi szoftver minden költsége megvan, a tulajdonlásból viszont semmi: olyan kódbázis, amelyet nem tudnak elolvasni, olyan helyen üzemeltetve, amelyet nem felügyelnek, olyan nyelven írva, amely egyetlen termékben létezik, olyan partner karbantartásában, akinek a napidíja immár tétel a költségvetésben. Az egyedi szoftverfejlesztés költségéről szóló útmutatónk bemutatja, hogyan gyűlnek össze ezek a számok.

Árulkodó jelek, hogy a csapdában vannak

A csapdát könnyebb észrevenni, mint elhagyni, és a jelek félreérthetetlenek, amint keresni kezdik őket.

• A bevezetési partner díja nagyobb, mint az első év licencdíja.
• Valaki gyakorlatilag teljes állásban egyetlen termék adminisztrálásával foglalkozik.
• Logikát írtak a szállító saját szkriptnyelvén, és a cégen kívül senki nem tudja elolvasni.
• A szállító minden frissítése a testreszabások regressziós tesztelését váltja ki, ezért halogatják a frissítéseket.
• Fizetnek egy integrációs platformért, amely csak azért létezik, hogy ezt az egy terméket adatokkal ellássa.
• A termék mellett árnyéktáblázatot vezetnek, mert a termék nem tud kifejezni valamit, amire szükségük van.

Az utolsó a legvilágosabb. Ha a táblázat túlélte a szoftvervásárlást, a szoftver nem oldotta meg a problémát.

A no-code és a low-code mint komoly harmadik út

A no-code vagy egyedi fejlesztés kérdése többet érdemel egy lábjegyzetnél, mert a belső eszközök fejlesztésében a low-code platformok gyakran a helyes válaszok, és nem játékszerek.

Az olyan platformok, mint az Airtable, a Retool és a Microsoft Power Apps, valódi többfelhasználós alkalmazást engednek építeni adatbázissal, űrlapokkal, jogosultságokkal és automatizmusokkal, hónapok helyett napok alatt, anélkül hogy bárkit fel kellene venni. Ellátják a tárhelyet, a mentéseket, a bejelentkezést és a mobil elrendezést. Arra a konkrét feladatra, hogy egy teherhordóvá vált táblázat rendes hozzáférés-szabályozást és naplózást kapjon, gyakran ezek a leggyorsabb utak egy nagy kockázatcsökkentéshez.

Emellett férőhely alapján árazzák őket, és éppen ez dönti el, hogy növekedés közben is helyes válasz maradnak-e.

Hol nyer valóban a no-code

Akkor nyer, ha a feladat alakja rekordokból, űrlapokból, nézetekből és egyszerű szabályokból áll: eszköznyilvántartás, jóváhagyási sor, ügyfélfogadási ellenőrzőlista, teremfoglalás. Akkor nyer a legnagyobb fölénnyel, ha az az ember építheti meg, aki a folyamatot érti, mert így a követelményeknek soha nem kell túlélniük a specifikációba és vissza fordítást.

Nyer az értékig eltelt időben is. Egy két hét alatt elkészült, naponta használt eszköz többet ér, mint egy hat hónap múlva tökéletes, amely még mindig tervezés alatt áll, és a megépített változat megtanítja, mik voltak valójában a követelmények.

Hol ütközik falba a no-code

A fal általában öt dolog egyike. A teljesítmény valódi sorszámoknál, amint egy nézetnek több százezer rekordot kell szűrnie. A valóban összetett jogosultságok, például soronkénti szabályok, amelyek a rekord állapotától és a néző csapatától függenek. A tranzakciós épség, ahol két dolognak vagy mindkettőnek meg kell történnie, vagy egyiknek sem. A tesztelés és a verziókezelés, mert gyakran semmilyen módon nem lehet átnézni egy változtatást élesítés előtt. És bármi, amiben valódi állapotgép van, ahol szabályok mondják meg, mely átmenetek megengedettek.

A falhoz nem fokozatosan érnek oda. Akkor érnek oda, amikor egy egyórásnak tűnő változtatásról kiderül, hogy lehetetlen.

Mit művel nagy méretben a férőhely alapú árazás

A férőhely alapú árazás tíz felhasználónál olcsó, négyszáznál pedig védhetetlen lehet, és a közzétett díjak ezt könnyen megmutatják.

A Retool árazási oldala a Business csomagot a brit felhőre havi GBP 40 összeggel sorolja fel fejlesztőnként és GBP 12 összeggel belső felhasználónként, a Team csomagot pedig GBP 8 és GBP 4 összeggel. A Microsoft a Power Apps Premium csomagot éves fizetés mellett havi GBP 16,90 áron adja felhasználónként, áfa nélkül, ami GBP 10,80 értékre csökken 2 000 férőhelyes minimum mellett. Az Airtable a Team csomagot USD 20, a Business csomagot USD 45 áron teszi közzé felhasználónként havonta, mindkettőt éves számlázással, amerikai dollárban.

Vetítsék ezt előre. Negyven felhasználó a Retool Business csomagján, közülük hárman fejlesztők, évi nagyjából GBP 6 800 összeget tesz ki. Ugyanez a felállás négyszáz felhasználóval évi körülbelül GBP 59 600 összeg, és tovább nő abban a pillanatban, amint embereket vesznek fel. A Power Apps Premium csomagján négyszáz férőhely évente körülbelül GBP 81 000 összeg áfa előtt.

Ezek közül egyik díj sem ésszerűtlen. A lényeg az, hogy a számla a létszámot követi, nem a kiszállított értéket, a létszám pedig nő.

A kilépés problémája, amikor a logika saját fejlesztésű eszközben él

Minden platform exportálja az adatokat. Egyik sem exportálja az alkalmazást.

A sorok CSV formában vagy programozói felületen keresztül kijönnek, és aláírás előtt mindenki ezt a részt ellenőrzi. Ami nem jön ki, az éppen az, amit felépítettek: az automatizmusok, a képletoszlopok, a jogosultsági szabályok, a feltételes űrlapok, az a folyamat, amely egy igényből három értesítést és egy állapotváltozást csinál. Az a logika az érték, hónapokba telt jól eldönteni, és csak egyetlen szállító futtatókörnyezete tudja lefuttatni.

A gyakorlati következmény az, hogy egy low-code platform elhagyása nem költözés, hanem újraépítés. Visszakapják az adatokat, és máshol újra megírják az alkalmazást, olyan specifikáció alapján, amelyet soha nem írtak le, mert a specifikáció maga a platform volt.

Ez nem érv az ilyen platformok használata ellen, csak amellett, hogy a szabályok írásos leírását az eszközön kívül is vezessék.

Ötéves teljes bekerülési költség a három úton

Az az összehasonlítás, amelyet szokás megtenni, egy meghatározott módon becstelen: az egyik út teljesen kalkulált változatát állítja a másik listaárával szembe. Vegyenek negyven felhasználót és egy működési alkalmazást, amely egy táblázatot és két kis előfizetést vált ki. A számok szemléltető tervezési értékek, nem ajánlatok, és az építési ár az a tényező, amely a legtöbbet mozdul.

Szöveggel olvasva: negyven felhasználónál a no-code platform nyer, öt év alatt nagyjából GBP 75 800 összeggel. Az egyedi fejlesztés a második, körülbelül GBP 94 500 összeggel, mert egy GBP 45 000 értékű építés, mellette GBP 1 800 tárhellyel és GBP 8 100 éves karbantartással még mindig veri a SaaS út egymásra rakódó licencét, köztes rétegét és adminisztrációját. A termék megvásárlása lesz az utolsó, körülbelül GBP 135 000 összeggel, és nem a licenc miatt, hanem a középső csapda miatt.

Miért fordul meg ugyanez a táblázat négyszáz felhasználónál

Változtassanak meg egyetlen bemenetet, a létszámot, és a sorrend teljesen megfordul. Ez a leggyakoribb oka annak, hogy egy fejlesztés ésszerűvé válik.

Négyszáz felhasználónál a havi GBP 30 férőhelyenkénti SaaS licenc önmagában évi GBP 144 000 összeg, és ugyanazzal a köztes réteggel meg egy nagyobb adminisztratív teherrel az ötéves végösszeg meghaladja a GBP 800 000 értéket. A no-code út GBP 375 000 közelében áll meg. Az egyedi fejlesztés alig mozdul: több felhasználó valamivel nagyobb tárhelyszámlát és karbantartási keretet jelent, így még az építési ár megkétszerezése GBP 70 000 összegre is GBP 153 000 közelében hagyja az ötéves végösszeget.

Az ok szerkezeti. A férőhely alapú árazás változó költség, amely a szervezettel együtt nő, míg az egyedi rendszer állandó költség plusz egy kis változó rész, és ez a rész az infrastruktúra, amely olcsó. Az, hogy a megfordulás számít-e önöknek, üzleti előrejelzés kérdése, nem műszaki ítéleté.

Az egyedi fejlesztés folyamatos költségküszöbe

Az a sor, amelyet az egyedi árajánlatokból kihagynak, éppen az, amely soha nem áll meg. Egy egyedi alkalmazásnak költségküszöbe van, és ez nem esik nullára egy csendes évben sem, amikor senki nem kér új funkciót.

A küszöb tárhelyből, felügyeletből, olyan mentésekből áll, amelyek visszatöltését kipróbálták, TLS-tanúsítványokból, biztonsági javításokból, függőségek frissítéséből és valakiből, aki felveszi a telefont, amikor hétfőn kilenckor elszáll. Tervezzenek évente az eredeti építési költség nagyjából 15-20 százalékával. Ez tervezési feltevés abból, ahogy az ilyen projektek viselkednek, nem pedig közzétett statisztika, de ez az a szám, amelyre költségvetést készítünk, és az az ajánlat, amelyből hiányzik, nem teljes ajánlat. A szoftverkarbantartás költségéről szóló írásunk ezt tovább bontja.

A fenti egyedi ötéves végösszegek mindegyike feltételezi, hogy ez a sor finanszírozott. Azok a projektek, amelyek kihagyják, nem takarítják meg a pénzt, csak elhalasztják, és később újraírásként fizetik ki, ami pontosan az, amit a technikai adósság leír.

A nem karbantartott szoftver romlik

Az az alkalmazás, amely két éve érintetlenül fut, nem stabil. Javítatlan, és ez a különbség számít.

A kódban semmi nem változott, körülötte viszont minden. A nyelvi futtatókörnyezetek közzétett menetrend szerint érnek az életciklusuk végére: a Node.js jelenleg a 26-os változatot támogatja aktuálisként, a 24-es és a 22-es változatot pedig aktív LTS ágként, ami azt jelenti, hogy minden, ami a 20-as vagy korábbi változatra épül, támogatáson kívül van, és nem kap biztonsági javítást. A függőségek közzétett sebezhetőségeket halmoznak fel. A böngészők megváltoztatják, hogyan kezelik a sütiket és a tárolást. A fizetési szolgáltatók kivezetnek felületi verziókat, és határidőt adnak.

Egyik sem az önök hibája, és mindegyik az önök gondja, mert egy egyedi rendszerben nincs szállító, aki felfogná ezeket önök helyett. Ez a vásárlás valódi, szerkezeti előnye: valaki más fejlesztőcsapata minden héten azzal tölti az idejét, hogy megakadályozza a padló korhadását, és a licencdíj ennek az ára. A saját karbantartási keretük pontosan ugyanezt a munkát veszi meg, és vagy tudatosan fizetik ki, vagy vészhelyzetben.

A saját férőhely alapú fordulópontjuk megkeresése

A fordulópont körülbelül tíz perc alatt kiszámolható, és egy pénzügyi vezetőt jobban meggyőz bármilyen tulajdonlásról szóló érvnél.

Vegyék a termékút havi költségét, mindenestől: licenc, köztes réteg és az a bérhányad, amely az üzemeltetésére megy el. Vonják ki egy egyedi rendszer havi működési költségét, vagyis a tárhelyet plusz az éves karbantartási keret egytizenketted részét. Osszák el az építési árat azzal, ami marad. Az eredmény az a hónapszám, ameddig a fejlesztés megtérül.

Negyven felhasználóra végigszámolva: a SaaS út havonta körülbelül GBP 2 150 összeggel fut, az egyedi rendszer pedig körülbelül GBP 825 összeggel, így a havi megtakarítás nagyjából GBP 1 325. Egy GBP 45 000 értékű fejlesztés körülbelül 34-szer fér bele ebbe, tehát a megtérülés két év tíz hónap közelébe esik. Négyszáz felhasználónál a megtérülés egy év alá csökken.

Két megszorítás. Az építési ár itt a legbizonytalanabb szám, ezért számolják ki a kapott ajánlattal, majd újra 50 százalékkal magasabb értékkel. És a nagyjából három évnél hosszabb megtérülés gyenge érv, mert a folyamatuk talán nem éli túl változatlanul ilyen sokáig.

Az adat és a bezáródás mindkét irányba vág

A szállítói bezáródás a fejlesztés melletti szokásos érv, és valós. Ugyanakkor a kép fele csupán, mert az az egyedi rendszer is bezár, amelyet senki nem dokumentált.

A termék oldalán aláírás előtt nézzék meg, mi jön ki valójában. A rekordok általában tisztán exportálhatók. A csatolmányok, a régi naplók, a hozzászólások, a jogosultsági szerkezetek és a rekordok közötti kapcsolatok gyakran nem. A gyakorlati mérce nem az, hogy van-e exportgomb, hanem az, hogy pusztán az exportból fel tudnának-e állítani egy működő helyettesítőt.

Az egyedi oldalon az ezzel egyenértékű, ellentétes kockázat egy olyan rendszer, amelyet egyetlen külsős épített README nélkül, tesztek nélkül, üzemeltetési kézikönyv nélkül, laptopon lévő konfigurációs fájlba írt belépési adatokkal és valakinek a személyes fiókjában lévő tárolóval. Ez rosszabb a SaaS bezáródásnál, mert a szállító legalább még működik.

Az ellenszerek szerződésesek, és az elején olcsó ragaszkodni hozzájuk. Legyen a saját tulajdonukban a kódtároló, kérjék a dokumentációt és az üzemeltetési kézikönyvet nevesített szállítandóként, és kérjék, hogy egy második mérnök pusztán abból a dokumentációból üzembe tudja helyezni. Ezt fizetés előtt ellenőrizzék le. Teljes vevői útmutatónk részletesebben tárgyalja a szerződéses feltételeket.

Biztonság és megfelelés az egyes modellekben

A felelősség megosztása utanként eltér, egyvalami viszont egyáltalán nem mozdul, és ennek elrontása gyakori.

A UK GDPR szerint önök az adatkezelő. Az ICO az adatkezelőt úgy határozza meg, mint azt a szervezetet, amely önállóan vagy másokkal közösen megállapítja a személyes adatok kezelésének céljait és eszközeit, az adatfeldolgozót pedig úgy, mint azt, amely az adatkezelő nevében kezel személyes adatot. A SaaS szállítójuk szinte mindig az adatfeldolgozó. Önök maradnak felelősek a megfelelés igazolásáért, és az ICO kifejezetten kimondja, hogy az adatkezelő felel az adatfeldolgozóiért, és kötelező erejű szerződést kell tartania a 28(3) cikk által megkövetelt rendelkezésekkel.

Amit a szállító valóban visz, az az infrastruktúra rétege: fizikai biztonság, platformjavítások, hálózati kontrollok és gyakran tanúsítványok. Az NCSC megosztott felelősségi modellje egyértelmű abban, hogy SaaS esetén is három dolog önöknél marad: megítélni, hogy a szolgáltatás megfelel-e a biztonsági igényeiknek, biztonságosan beállítani, és eldönteni, milyen adatot tesznek bele.

Egyedi fejlesztésnél a teljes műszaki réteget is öröklik: javítás, hozzáférés-szabályozás, titkosítás, naplózás, mentés és visszaállítás. A GDPR műszaki megfeleléséről szóló írásunk bemutatja, hogyan néz ki ez kódban. A jogi helyzet utak között nem változik.

Az akadálymentesség a belső eszközökre is vonatkozik

A belső eszközöket rendszeresen úgy építik, mintha senki sem lehetne fogyatékossággal élő azok közül, akik használják, ami téves, és egyes szervezeteknél ráadásul jogellenes.

Az Equality Act 2010 20. szakasza szerint a munkáltatónak ésszerű alkalmazkodási kötelezettsége van, ideértve azoknak a lépéseknek a megtételét, amelyek ésszerűen megtehetők egy rendelkezésből, feltételből vagy gyakorlatból eredő lényeges hátrány elkerülésére, valamint segédeszközök biztosítását. Egy beosztási rendszer, amelyet billentyűzetről nem lehet kezelni, lényeges hátrányba hozza a fogyatékossággal élő munkavállalót, és nincs kivétel arra a szoftverre, amelyet az ügyfelek soha nem látnak.

A közszféra szervezeteinél a helyzet kifejezett. A GOV.UK akadálymentesítési követelményekről szóló útmutatója kimondja, hogy az intranetes és extranetes webhelyekre kiterjednek az akadálymentesítési szabályok, hogy meg kell felelniük a WCAG 2.2 AA szintjének, és hogy a 2019. szeptember 23. előtt közzétett régebbi belső webhelyeket akkor kell akadálymentessé tenni, amikor frissítik őket.

Azok a feltételek, amelyeken a belső eszközök a leggyakrabban elbuknak, a hétköznapiak: A szinten a 2.1.1 Billentyűzet és a 3.3.2 Címkék vagy utasítások, AA szinten az 1.4.3 Kontraszt (minimum), a WCAG 2.2 kiegészítései közül pedig a 2.4.11 Nem takart fókusz (minimum) és a 2.5.8 Célméret (minimum), mindkettő AA szinten.

No-code esetén az akadálymentesség olyan plafon, amelyet nem önök szabnak

Ez az az akadálymentességi szempont, amely megváltoztat egy építeni vagy venni döntést, ahelyett hogy csak munkát adna hozzá.

No-code platformon nem önök írják a jelölőkódot. A platform állítja elő, így az alkalmazásuk akadálymentessége a platform komponenskönyvtáráénál nem lehet jobb. Ha a dátumválasztóját nem lehet billentyűzetről kezelni, vagy a felugró ablaka rosszul tartja a fókuszt, ezt nem tudják megjavítani. Nyithatnak egy támogatási jegyet, és várhatnak.

Ez rendben van, amíg a plafon elég magas, és több platform komolyan veszi a kérdést. Nincs rendben, ha konkrét kötelezettségük, konkrét munkavállalójuk vagy közszférás kötelességük van, mert az orvoslás az önök hatókörén és határidején kívül esik.

Egyedi fejlesztésnél az akadálymentesítés munkája az önöké, ami elöl többe kerül, viszont megszünteti a függést. Kérjenek minden szóba jövő szállítótól akadálymentességi megfelelőségi nyilatkozatot, mielőtt folyamatot terveznek a komponensei köré, és a hiányát tekintsék válasznak.

Az egyedi fejlesztés kockázatának csökkentése vékony első szelettel

Az egyedi projektek általában nem műszaki okból buknak el. Azért buknak el, mert a teljes keretet olyan specifikációra kötik le, amelyet még azelőtt írtak, hogy bárki bármit használt volna.

Az alternatíva egy vékony szelet: egyetlen munkafolyamat, elejétől a végéig, éles üzemben, egyetlen valódi ember valódi munkájában használva, hat-nyolc hét alatt. Nem prototípus és nem bemutató, hanem a legkeskenyebb út a rendszeren át, amely valódi eredményt hoz, valódi adattal, valódi bejelentkezéssel és valódi élesítéssel. Ha a folyamat az árajánlat, akkor a szelet ajánlatot készít, beárazza és elküldi.

Ez a szelet négy olyan dolgot tesz, amit specifikáció nem tud. Igazolja az integrációkat, ahol a meglepetések laknak. Megméri a csapat valódi szállítási ütemét, ahelyett hogy becsülné. Működő szoftvert tesz annak az embernek az elé, akié a folyamat, ami megbízhatóan megváltoztatja a követelményeket. És kiutat ad: meghatározott összeget költöttek el, és van valamijük, ami működik.

Aztán tegyenek oda egy döntési pontot, írásban, mielőtt a nagyobb kiadás felszabadul. A webalkalmazás építéséről szóló útmutatónk az első szelet műszaki alakját tárgyalja, szoftverfejlesztési szolgáltatásaink oldala pedig elmagyarázza, hogyan határolunk körül egyet.

Döntési keret, amelyet egy délután alatt végig lehet vinni

Ehhez semmiképp nem kell tanácsadói megbízás. Néhány óra kell hozzá és őszinteség a számokkal.

Először írják le a folyamatot úgy, ahogy valójában zajlik, lépésekben, beleértve a kézzel kezelt kivételeket is. Ez önmagában gyakran lezárja a vitát, mert kiderül belőle, hogy nem egy, hanem három folyamatról van szó.

Másodszor számolják meg a mai férőhelyeket, és becsüljék meg őket három évre. Harmadszor válasszanak ki pontosan három terméket, és a saját leírt folyamatuk szerint pontozzák őket, ne a funkciólistájuk szerint, megjelölve minden pontot, ahol a termék bevezetése megváltoztatná a munkamódjukat, és azt is, hogy ez a változás kerül-e valamibe.

Negyedszer árazzák be kifejezetten a középső csapdát: bevezetési díjak, köztes réteg és az a bérhányad, amely majd üzemelteti. Ötödször alkalmazzák a kettő a háromból tesztet. Hatodszor számolják ki a fordulópontot hónapban mindkét férőhelyszámra. Hetedszer, ha a válasz az egyedi fejlesztés, rendszer helyett vékony szeletet rendeljenek.

Kinek kellene bezárnia ezt a lapot és vennie valamit

Néhány olvasónak itt abba kellene hagynia, és ezt kimondani hasznosabb egy kiegyensúlyozott zárszónál.

Ha a folyamatuk általános, és több ezer cég nagyjából ugyanígy futtatja, vegyék meg a terméket. Ha nagyjából húsz felhasználónál kevesebben vannak, és nincs olyan előrejelzés, amely ezt megváltoztatja, vegyék meg a terméket, vagy építsék meg no-code platformon, mert a férőhelyenkénti számtan semmilyen tervezhető időtávon nem fordul a javukra. Ha átadás után senki nem lesz a szoftver gazdája, vegyék meg a terméket, mert a gazdátlan egyedi rendszer gyorsan teherré romlik.

Ha nem tudják írásban leírni a folyamatukat, még ne rendeljenek semmit. Írják le előbb. Sok bukott projektet olyan leírásra rendeltek meg, amelyet ugyanabban a szobában három ember háromféleképpen értett, és ezt semennyi fejlesztés nem javítja meg.

Ha a három feltételből csak egy teljesül, vegyék meg a terméket, és nézzék meg újra egy év múlva. A feltételek változnak, általában azért, mert nőtt a létszám. És ha valójában nyilvános webhelyre van szükségük belső eszköz helyett, az másik projekt, amelyet a webhelyfejlesztési munkánk fed le.

Második vélemény, mielőtt elköteleződnek

A drága hibát mindkét irányban azelőtt követik el, hogy bármilyen kód létezne, ezért a legolcsóbb dolog, amit most vehetnek, egy őszinte értékelés.

A Mecanik működési webalkalmazásokat épít brit cégeknek, és ennek a munkának nagy része az, hogy elmondjuk az embereknek, nincs rá szükségük. Hozzák el a táblázatot, a férőhelyszámot és a három kiválasztott terméket, és az egyedi szoftverfejlesztő csapatunk vagy beáraz egy vékony első szeletet, vagy megmondja, melyik terméket vegyék meg helyette. Ha az alkalmazás ügyfeleknek szól és nem belső használatra, kezdjék a webhelyfejlesztéssel, és olvassák el az egyedi webfejlesztés és a SaaS platformok összehasonlítását, amely a kérdés másik oldalát tárgyalja.

Gyakran ismételt kérdések

Mennyibe kerül egy egyedi webalkalmazás az Egyesült Királyságban? Egy jól körülhatárolt belső alkalmazás, amely egy táblázatot és egy-két előfizetést vált ki, jellemzően GBP 25 000 és GBP 60 000 közötti összegbe kerül, ebből a vékony első szelet GBP 8 000 és GBP 15 000 közötti részt visz el. Tervezzenek be évente további 15-20 százalékot az építési árból tárhelyre, javításokra és függőségfrissítésekre, mert ez a költségküszöb soha nem éri el a nullát.

Valódi alternatíva a no-code az egyedi webalkalmazás fejlesztéssel szemben? Igen. Rekordokra, űrlapokra, nézetekre és egyszerű szabályokra gyakran ez a helyes válasz, és sokkal gyorsabb. Falba ütközik nagy sorszámoknál, összetett jogosultságoknál, tranzakciós épségnél, verziókezelésnél és valódi állapotgépeknél. Emellett férőhely alapján árazzák: a Retool a Business csomagot havi GBP 40 összeggel adja fejlesztőnként és GBP 12 összeggel belső felhasználónként, ami tíz férőhelynél olcsó, négyszáznál viszont tetemes.

Hány felhasználótól lesz olcsóbb az építés a vásárlásnál? Osszák el az építési árat a havi megtakarítással, vagyis a termék teljes költségével csökkentve a tárhellyel és az éves karbantartási keret egytizenketted részével. Negyven felhasználónál egy GBP 45 000 értékű fejlesztés egy havi GBP 2 150 termékköltséggel szemben nagyjából 34 hónap alatt térül meg. Négyszáz felhasználónál egy éven belül megtérül, mert a férőhelydíjak a létszámmal nőnek, míg az egyedi rendszer működési költsége alig mozdul.

Ki felel az adatvédelemért, ha építés helyett SaaS-t veszünk? Önök. Az ICO az adatkezelőt úgy határozza meg, mint azt a szervezetet, amely megállapítja az adatkezelés céljait és eszközeit, a SaaS szállítójuk pedig szinte mindig az utasításaik szerint eljáró adatfeldolgozó. Önök maradnak felelősek a megfelelés igazolásáért, az adatfeldolgozóik megfeleléséért és a 28(3) cikk szerinti szerződésért. A szoftver megvásárlása az infrastruktúra munkáját teszi át, a jogi felelősséget nem.

Vonatkoznak az akadálymentességi szabályok olyan belső eszközre, amelyet kívülről senki sem lát? Igen. Az Equality Act 2010 20. szakasza ésszerű alkalmazkodást ír elő a munkáltatóknak, és az az eszköz, amelyet billentyűzetről nem lehet kezelni, lényeges hátrányba hozza a fogyatékossággal élő munkavállalót. A közszféra intranetjeire és extranetjeire ezenfelül kiterjednek az akadálymentesítési szabályok, és meg kell felelniük a WCAG 2.2 AA szintjének. No-code platformon az akadálymentesség plafonját a szállító komponensei szabják meg.