Bizalom és átvilágítás

Mielőtt a FlowOne-ra bízod a céged működését, tegyél minket próbára.

Kérdezd meg, mi történik, ha kiesik egy szerver. Kérdezd meg, mennyi adat veszhet el. Kérdezd meg, hogyan lehet kilépni a FlowOne-ból. Kérdezd meg, mi történik, ha mi megszűnünk. Kérdezd meg, hogyan állítható vissza egy migráció. Ezek nem kellemetlen kérdések. Pont ezeket kell megválaszolni, mielőtt egy üzletkritikus platform bekerül a cégedbe.

Mi történik, ha megszűntök?
Vissza tudunk állni?
Pontosan mit garantál az SLA?
Kié az adatunk?
Mikor teszteltétek utoljára a helyreállítást?
Mennyibe kerülne kilépnünk?
01

Ne azért bízz bennünk, mert ezt kérjük.

A FlowOne nem Microsoft és nem SAP. Egy üzletkritikus bevezetésnél ez még fontosabbá teszi a folytonossági tervezést — nem kevésbé fontossá. Ezért ne fogadj el semmit pusztán azért, mert mi mondjuk.

Ezen az oldalon minden állítást úgy fogalmaztunk meg, hogy ellenőrizhető legyen, ne csak elhidd. Pontosan erről szól az átvilágítás.

1

Vizsgáld meg az architektúrát

2

Teszteld a helyreállítási eljárásokat

3

Rögzítsd az SLA-t

4

Ellenőrizd a migrációt

5

Nézd át a szerződést

6

Értsd meg a kilépési tervet

02

Az adatod a tiéd.

A tulajdonjog nem marketingüzenet, hanem szerződésben rögzített jogok összessége.

Tulajdonjog: a FlowOne soha nem szerez tulajdonjogot az ügyfél üzleti adatai felett.

Megőrzés: szerződéses szabályok rögzítik, hogy az adatokat meddig és hol tároljuk.

Exportálás: strukturált formátumban bármikor kiviheted az adataidat anélkül, hogy ehhez engedélyt kellene kérned.

Törlés: dokumentált eljárás alapján töröljük az adatokat kérésre vagy a szerződés megszűnésekor.

Biztonsági mentések életciklusa: a mentések előre meghatározott ütemezés szerint járnak le, és a törlési folyamat ezekre is kiterjed.

Hordozhatóság: nyílt formátumok, dokumentált struktúra, saját formátumokba zárás nélkül.

03

A bezártság nem lehet üzleti modell.

Azt szeretnénk, hogy azért maradj a FlowOne mellett, mert a rendszer folyamatosan bizonyítja az értékét — ne azért, mert lehetetlen elköltözni. Értékkel akarunk megtartani, nem az adataid fogva tartásával.

Különbséget teszünk a természetes platformfüggés és a mesterséges bezártság között. Egy integrált rendszer bizonyos mértékű függőséget mindig létrehoz. A mesterséges bezártság viszont tervezési döntés.

04

Nem egyetlen vak ugrással költöztetjük át a cégedet.

A „mindent egy hétvége alatt” típusú migrációk azért veszélyesek, mert egyetlen időpontra tesznek fel mindent. Mi ellenőrzött szakaszokban migrálunk, miközben a meglévő rendszereid végig működnek.

Migrációs konzol
  1. 1Leltár
  2. 2Leképezés
  3. 3Tömeges migráció
  4. 4Delta migráció
  5. 5Egyeztetés
  6. 6Felhasználói elfogadási teszt
  7. 7Átállás
  8. 8Ellenőrzés
Régi rendszerek
Hiteles forrás
FlowOne
Tömegesen migrált rekordok0
Delta-változások rögzítve
Egyeztetés: a darabszámok egyeznek
Átállás utáni ellenőrzés sikeres
A meglévő rendszerek közben végig működnek
05

A tesztelés csökkenti a kockázatot. A visszaállási terv pedig abból indul ki, hogy kockázat ettől még mindig létezik.

Mi történik, ha hétfő reggel valami nem működik megfelelően? Erre a kérdésre az átállás előtt kell válaszolni, nem utána.

A visszaállási terv nélküli migrációs terv befejezetlen.

A régi rendszereket egy előre meghatározott visszaállási időszak alatt továbbra is megtartjuk.

A visszaállás feltételeit még az élesítés előtt rögzítjük — nem egy incidens közben próbáljuk eldönteni.

Az átállás után létrejövő változásokat követjük, hogy semmi ne vesszen el abból, amit a felhasználók már az új rendszerben hoztak létre.

A visszaállási tervet az átállás előtt dokumentáljuk és elpróbáljuk.

Az egyeztetés az új rendszerben létrehozott rekordokra is kiterjed.

A mehet / nem mehet döntés felelőse előre rögzített.

06

A magas rendelkezésre állás nem ugyanaz, mint a biztonsági mentés.

Egy biztonsági mentésből idővel vissza tudod állítani az adataidat. A magas rendelkezésre állás azt biztosítja, hogy a munkatársaid egy meghibásodás közben is tovább tudjanak dolgozni. Két külön területről van szó, ezért külön is tervezzük őket.

Magas rendelkezésre állás

Magas rendelkezésre állás

  • Redundáns alkalmazásszolgáltatások
  • Folyamatos adatreplikáció
  • Automatikus failover, ahol támogatott
  • Állapotfigyelés minden rétegen
Katasztrófa-helyreállítás

Katasztrófa-helyreállítás

  • Független, titkosított biztonsági mentések
  • Különálló helyreállítási környezet
  • Dokumentált visszaállítási eljárások
  • Telephelyen kívüli védelem
Üzemeltetési monitorozás

Üzemeltetési monitorozás

  • Folyamatos állapotellenőrzések
  • Hibaészlelés és eszkaláció
  • Automatikus beavatkozás, ahol ez biztonságosan megoldható
  • Az automatizálás mögött szükség esetén emberi ügyelet áll

A szerződéses rendelkezésre állást, RPO-t és RTO-t mindig a kiválasztott infrastruktúra és szolgáltatási szint alapján rögzítjük.

07

Ha minden meghibásodik, két szám válik azonnal fontossá.

A katasztrófa-helyreállítás minden más részlete ezek köré épül. Ez a két érték határozza meg, hogy egy nagyon rossz nap mekkora üzleti hatással jár.

RPO

Legfeljebb mennyi friss adat veszhet el?

Recovery Point Objective. 5 perces RPO esetén a legrosszabb forgatókönyv szerint körülbelül az utolsó öt perc változásait kell helyreállítani.

RTO

Mennyi idő alatt működik újra a szolgáltatás?

Recovery Time Objective. 30 perces RTO esetén a szolgáltatás a meghibásodást követő fél órán belül újra működik — függetlenül attól, melyik komponens hibásodott meg.

Gyakorlatokon mért értékek — nem szerződéses SLA

Rendszeres failover-gyakorlataink során a tartalék kiszolgáló 4–6 percen belül átveszi a működést, miközben a replikációs késés 30 másodperc alatt marad.

Nézd meg a failover-visszajátszást

Különböző incidensekhez különböző vállalások tartoznak

ForgatókönyvRPORTO
Egyetlen node kieséseHA SLAHA SLA
Elsődleges szerver kieséseHA SLAHA SLA
Teljes telephely kieséseDR SLADR SLA
Visszaállítás biztonsági mentésbőlMentési SLAVisszaállítási SLA

A szerződéses értékeket minden telepítésnél és szolgáltatási szintnél külön rögzítjük — írásban, még azelőtt, hogy elköteleződnél.

08

Egy észrevétlenül leálló integráció rosszabb, mint ha nem lenne integráció.

Ha egy integráció látványosan hibázik, valaki észreveszi és kijavítja. Ha viszont csendben áll le, a két rendszer elkezd eltérni egymástól, és lehet, hogy csak egy ügyfél jelzi először a problémát. Mi erre a második esetre is tervezünk.

Újrapróbálás és várólisták

Az átmeneti hibák esetén a rendszer automatikusan újrapróbálkozik. Egyetlen művelet sem tűnik el nyomtalanul.

Látható hibák

Ha egy integráció leáll, riasztást generál. Nem maradhat észrevétlenül csendben.

Egyeztetés

Ütemezett összehasonlítások ellenőrzik, hogy a rendszerek adatai továbbra is megegyeznek — nem elég az, hogy az üzenetek technikailag átmentek.

Auditnapló

Minden szinkronizálás naplózott: mi mozdult, mikor történt, és milyen változást okozott.

Idempotencia

Egy művelet újbóli lefuttatása nem hoz létre duplikációkat ott, ahol ez problémát okozhat.

Kézi beavatkozás

Előre definiált emberi beavatkozási folyamat áll rendelkezésre, amikor az automatizálásnak meg kell állnia.

Hiteles adatforrás

Minden mezőnél előre meghatározzuk, melyik rendszer az elsődleges adatforrás. Ezt nem incidens közben kell eldönteni.

Honnan tudod, hogy a rendszereid holnap is ugyanazt az adatot mutatják?

09

A biztonság architektúra, üzemeltetés és elszámoltathatóság.

Nem egyszerű funkciólista. Olyan egymásra épülő védelmi rétegek összessége, amelyeknek egy IT-biztonsági csapat részletes kérdéseit is ki kell állniuk.

Hitelesítés Jogosultságkezelés Titkosítás Auditálhatóság Infrastruktúra-izoláció Frissítések Sérülékenység-kezelés Biztonsági mentések Privilegizált hozzáférés Monitorozás Incidenskezelés

Ki fér hozzá az adatainkhoz?

Hogyan szabályozzátok az adminisztrátori hozzáférést?

Mi történik, ha egy felhasználói fiókot kompromittálnak?

Hogyan észlelitek és vizsgáljátok ki az incidenseket?

10

A célszámok hasznosak. A szerződéses vállalások többet érnek.

A szolgáltatási szint megállapodás, vagyis az SLA, mérhető formában rögzíti, mit vállal a FlowOne — és mi történik akkor, ha ezt nem teljesítjük. Ez a különbség egy prezentációban szereplő szám és egy aláírt vállalás között.

Rendelkezésre állás Kritikus incidens reakcióideje Támogatási eszkalációs folyamat RPO — maximális adatvesztés RTO — maximális helyreállítási idő Karbantartási időablakok Értesítési kötelezettségek Helyreállítási eljárások Kompenzáció, ahol alkalmazható
Műszaki célérték

Az az érték, amelynek elérésére az architektúrát terveztük és teszteltük. Ambiciózus és mért érték — de önmagában még nem szerződéses ígéret.

Szerződéses SLA

Amit aláírunk. Telepítésenként és szolgáltatási szintenként rögzített vállalás, a hozzá tartozó következményekkel. Ez az az érték, amely valóban számít.

Mit vagytok ténylegesen hajlandók írásba adni?

11

A céged működése nem függhet attól, hogy mi felvesszük-e a telefont.

Mi történik, ha a FlowOne megszűnik? A válasznak két része van: az adataid és maga a FlowOne szoftver. A pontos helyzet attól is függ, milyen telepítési modellt választottál.

A te adataid

  • Ügyféladatok
  • Dokumentumok és fájlok
  • Működési adatok
  • Exportok
  • Biztonsági mentések a szerződésben rögzítettek szerint

A FlowOne forráskódja továbbra is a FlowOne szellemi tulajdona marad, kivéve, ha ettől eltérő szerződéses megállapodás születik, például forráskód-letét. Ezt azért fogalmazzuk meg egyértelműen, mert egy ilyen kérdésre adott homályos válasz önmagában figyelmeztető jel.

A folytonosság a telepítési modelltől függ

Ügyfél által kontrollált telepítés

Ügyfél által kontrollált telepítés

A FlowOne az általad kontrollált infrastruktúrán fut. A te szervereid, a te hozzáféréseid, a te biztonsági mentéseid. A működő rendszer és az adatai akkor is a te kezedben maradnak, ha velünk bármi történik.

FlowOne által menedzselt infrastruktúra

FlowOne által menedzselt infrastruktúra

Mi üzemeltetjük helyetted, ezért ebben az esetben a szerződés biztosítja a folytonosságot. Dokumentált exporteljárások, mentésekhez való hozzáférés, migrációs támogatás és előre rögzített felmondási időszak — mindez még a bevezetés előtt meghatározható.

Vállalati folytonossági lehetőségek

  • Dokumentált exporteljárások
  • Hozzáférés a biztonsági mentésekhez a szerződésben meghatározott módon
  • Migrációs dokumentáció
  • Átállási támogatás
  • Előre rögzített felmondási időszak
  • Forráskód-letét, ahol üzletileg indokolt
12

Már azelőtt megtervezzük, hogyan tudsz kilépni, hogy szükséged lenne rá.

Az egyik legerősebb bizalmi jelzés, amit egy szolgáltató adhat, egy dokumentált kilépési lehetőség. A kilépési terv a bevezetés része — nem egy olyan tárgyalás, amelyet csak akkor kezdesz el, amikor a kapcsolat már megromlott.

Exportcsomag
flowone.pro
  • Adatok48 213 rekord
  • Fájlok12,6 GB
  • Metaadatokteljes előzmény
  • Felhasználók184 fiók
  • JogosultságokACL-mátrix
  • Integrációk23 leképezés
  • Dokumentációüzemeltetési runbookok
  • Átadásjóváhagyva
▪ ▪ ▪

A vállalati kilépési terv rögzítheti

  • Az exportformátumokat és azt, hogy pontosan mi exportálható
  • Az átállás időzítését és sorrendjét
  • A migrációs támogatást az átmeneti időszakban
  • A szerződés megszűnése utáni adatmegőrzést
  • Az átadás utáni törlési folyamatot
  • A hozzáférések és az infrastruktúra átadását, ahol ez releváns
  • Az extra átállási munka költségét
  • A forráskód-letétet, ha erről külön megállapodás születik

A kilépés járhat munkával. Engedélyt viszont soha nem kell kérned hozzá.

13

A skálázhatóságot a várható terheléshez mérten ellenőrizzük.

Mi történik, ha 20 felhasználóból 200 lesz? Vagy 2 000?

Nem elég azt mondani, hogy „a FlowOne skálázható”. A várható növekedésed alapján méretezzük, teszteljük és monitorozzuk az infrastruktúrát.

Ha a terhelés kinövi a jelenlegi telepítést, a következő infrastruktúra-szint terve már rendelkezésre áll.

Kapacitástervezés a várható terhelés alapján

Terheléses teszt a vállalások előtt, nem az első panaszok után

Infrastruktúra-méretezés telepítésenként

Horizontális és vertikális skálázás, ahol indokolt

Folyamatos teljesítmény-monitorozás

Adatbázis-növekedés és tárhelykapacitás tervezése

14

Egy technikailag sikeres migráció is lehet üzletileg sikertelen.

Mi történik, ha a munkatársak egyszerűen nem használják az új rendszert?

Ha a csapat tovább dolgozik a régi Excel-táblákban, akkor a projekt megbukott — teljesen mindegy, hogy a technikai átállási jelentés szerint minden rendben volt. A felhasználói bevezetést ezért ugyanúgy megtervezzük, mint a technikai migrációt.

A felhasználókat már a feltárási szakaszban bevonjuk, nem az indulás napján találkoznak először az új rendszerrel.

Valódi csapatokból választunk reprezentatív pilotfelhasználókat.

A munkafolyamatokat úgy alakítjuk ki, hogy ismerősnek hassanak, ne teljesen idegennek.

A képzés a különböző szerepkörökhöz igazodik.

Fokozatos bevezetés a teljes szervezet egyszerre történő átállítása helyett.

Folyamatos visszajelzés, látható eredményekkel.

15

Ha valami üzletkritikus, a „nyiss egy ticketet” nem elég.

A vállalati támogatás azt jelenti, hogy előre definiált út vezet onnan, hogy „valami baj van”, odáig, hogy „egy konkrét felelős ember már dolgozik rajta”.

Súlyossági szintek

Az incidenseket üzleti hatás alapján osztályozzuk, nem érkezési sorrendben.

Kritikus incidensfolyamat

Külön útvonal a kritikus problémáknak, amely nem a normál támogatási sorban várakozik.

Eszkaláció

Előre definiált eszkalációs lánc arra az esetre, ha egy probléma nem halad megfelelően.

Név szerinti kapcsolattartók

Ahol indokolt, konkrét emberekkel dolgozol — nem névtelen címekkel.

Műszaki kivizsgálás

Éles rendszerekhez hozzáférő mérnökök vizsgálják a problémát, nem kizárólag elsőszintű támogatási sablonok.

Incidens-kommunikáció

Leállás közben proaktív állapotjelentéseket kapsz.

Incidens utáni elemzés

A komolyabb hibákról írásos elemzés készül.

A reakció- és megoldási célidőket szolgáltatási szintenként a szerződéses SLA rögzíti. Számokat akkor teszünk közzé vállalásként, amikor készek vagyunk azokat alá is írni.

16

A helyreállítás csak a munka fele.

A szolgáltatás újraindítása a látható rész. Az érett üzemeltetést az mutatja meg igazán, mi történik utána.

Incidens-visszajátszás ÉLŐ
  1. 00:00
    ÉszlelésA monitorozás észleli a problémát — ideális esetben előbb, mint te.
  2. 00:02
    ElhatárolásMegállítjuk, hogy a probléma további rendszerekre is átterjedjen.
  3. 00:06
    HelyreállításA szolgáltatást a vállalt időablakon belül újra működőképessé tesszük.
  4. 00:11
    EllenőrzésNemcsak azt ellenőrizzük, hogy a rendszer elérhető-e, hanem az adatok sértetlenségét is.
  5. 00:14
    KommunikációÉrthetően elmondjuk, mi történt.
  6. 01:30
    KivizsgálásA valódi gyökérokot keressük, nem az első hihető magyarázatot.
  7. 02:15
    MegelőzésVáltoztatunk a rendszeren vagy a folyamatokon, hogy ugyanaz a probléma ne ismétlődhessen meg.

Komolyabb incidens után ezt kapod

  • Az incidens teljes idővonala
  • Gyökérok-elemzés
  • Az érintett szolgáltatások és adatok listája
  • A megtett javító intézkedések
  • Megelőző intézkedések, kijelölt felelősökkel
17

Arra számítunk, hogy az IT-, jogi és biztonsági csapatod kérdéseket fog feltenni.

Ha egy szolgáltató védekezni kezd az átvilágítás során, az önmagában információ. Hozd a kérdőívet. Ezek azok a területek, amelyeket készen állunk részletesen végigvenni.

Adatfeldolgozási megállapodás GDPR-megfelelés Al-adatfeldolgozók Adatok földrajzi helye Megőrzési szabályok Auditnaplók Hozzáférés-kezelés Biztonsági kérdőívek Architektúra-felülvizsgálat Behatolástesztek eredményei, ahol alkalmazható Üzletmenet-folytonossági dokumentáció Biztonsági mentési és DR-eljárások

Néhány tipikus kérdés — a válaszainkkal

EU-ban működő infrastruktúrán, a pontos helyszínt pedig a szerződés rögzíti. Ügyfél által kontrollált telepítés esetén az általad kiválasztott infrastruktúrán. Az adatokat szerződésmódosítás nélkül nem helyezzük át másik régióba, az adatfeldolgozási megállapodás pedig felsorolja azokat az al-adatfeldolgozókat, amelyek hozzáférhetnek az adatokhoz.

Igen. Az adatfeldolgozási megállapodás a standard szerződés része, nem külön megvásárolható kiegészítés. Az exportálás, helyesbítés és törlés dokumentált folyamatok szerint történik, előre egyeztetett határidőkkel — beleértve azt is, hogy egy törlési kérelem után mennyi ideig maradhat még adat a biztonsági mentésekben.

Egy szűk, név szerint meghatározott mérnöki körnek. A privilegizált hozzáférés naplózott és rendszeresen felülvizsgált. FlowOne által menedzselt infrastruktúrán mi kezeljük ezeket a hozzáféréseket, és minden használatukért elszámoltathatók vagyunk. Ügyfél által kontrollált telepítés esetén az infrastruktúra-hozzáférést a te csapatod kezeli, mi pedig ezen belül dolgozunk.

Igen. A csapatoddal együtt végig tudunk menni az architektúrán, kitöltjük a biztonsági kérdőíveket, és támogatjuk az előre egyeztetett behatolásteszteket. A talált problémákra dokumentált választ adunk.

Az adminisztratív műveletek és az adatváltozások naplózásra kerülnek: ki, mit és mikor módosított. A naplókat az előre egyeztetett szabályok szerint őrizzük meg, és egy vizsgálat során beilleszthetők a saját auditfolyamataitokba is.

Igen. A biztonsági mentési és katasztrófa-helyreállítási eljárásokat, valamint a visszaállítási gyakorlatok eredményeit NDA mellett meg tudjuk osztani. Az általunk publikált értékek valódi gyakorlatokon mért számok. Szívesebben mutatjuk meg a helyreállítási gyakorlat naplóját, mint egy jól hangzó marketingszámot.

18

Az első beszélgetéstől a stabil üzemeltetésig.

Minden szakasz azért létezik, hogy csökkentse a következő lépés kockázatát. Az ezen az oldalon bemutatott biztonsági és működési kontrollok nem különálló kiegészítések. A teljes folyamaton végighúzódnak.

Feltárás Feltérképezés Mérés Tervezés Demó Pilot Validálás Ütemezés Migráció Egyeztetés Teszt Átállás Támogatás Fejlesztés
SLA Biztonság HA DR Visszaállás Kilépési terv

A biztonsági korlátok a teljes folyamatot körülveszik — nem utólag kerülnek rá.

Tedd fel nekünk a nehéz kérdéseket.

Mi is ezeket kérdeznénk a helyedben.

A tartalék node automatikusan átveszi a működést — nincs szükség telefonhívásra vagy kézi beavatkozásra. Rendszeres failover-gyakorlataink során az átvétel 4–6 percen belül lezajlik, miközben a replikációs késés 30 másodperc alatt marad. Ezek gyakorlatokon mért értékek, nem szerződéses SLA-k. A pontos folyamatot az oldalon található failover-visszajátszás mutatja.

Pontosan ezért választjuk külön a magas rendelkezésre állást és a katasztrófa-helyreállítást. Független, titkosított biztonsági mentések, külön helyreállítási környezet és dokumentált visszaállítási eljárások állnak rendelkezésre. A helyreállítás a szerződésben rögzített DR-vállalások szerint történik — nem improvizálva.

A pontos érték a telepítéstől és a választott szolgáltatási szinttől függ. Ezeket írásban rögzítjük még azelőtt, hogy elköteleződnél. Az oldalon szereplő értékek gyakorlatokon mért eredmények. A szerződésben válnak tényleges, következményekkel járó vállalássá.

Mérhető vállalásokat: rendelkezésre állást, incidensreakciót, eszkalációs útvonalat, RPO-t, RTO-t, karbantartási időablakokat, értesítési kötelezettségeket és — ahol alkalmazható — kompenzációt. Szándékosan különválasztjuk a műszaki célértékeket attól, amit szerződésben is vállalunk.

A helyreállítást rendszeres ütemezés szerint gyakoroljuk, nem csak egyszer egy értékesítési prezentáció előtt. A tesztek naplóit és eredményeit NDA mellett meg tudjuk osztani. Kérd el a legutóbbi gyakorlatot, és megmutatjuk.

Egy leállt integráció riasztást generál. A csend önmagában hibaállapot. Az újrapróbálási és sorbaállítási mechanizmusok kezelik az átmeneti problémákat, az ütemezett egyeztetések ellenőrzik, hogy a rendszerek továbbra is megegyeznek, minden szinkronizálás pedig naplózott. Így az eltérés ideális esetben hamarabb kiderül, mint ahogy egy ügyfél észrevenné.

Egyeztetéssel, nem megérzés alapján. Összehasonlítjuk a régi és az új rendszer darabszámait, rekordjait, mellékleteit, jogosultságait és kritikus mezőit. Ezután a saját csapatod valódi munkafolyamatokkal végzi el a felhasználói elfogadási tesztet az átállás előtt.

A visszaállási terv már az átállás előtt elkészül és tesztelve van. A régi rendszerek a megállapodott visszaállási időszak alatt elérhetők maradnak, és a mehet / nem mehet döntés felelőse is előre rögzített. Egy sikertelen átállás tervezett forgatókönyv, nem váratlan válság.

Igen, a megállapodott visszaállási időszakon belül. Az átállás után létrejött változásokat követjük, és az egyeztetési folyamat ezek visszavezetésére is kiterjed. Ez nem utólagos ötlet, hanem a visszaállási terv része.

A tiéd. A FlowOne nem szerez tulajdonjogot az ügyfél üzleti adatai felett. A megőrzést, az exportjogot és a törlési folyamatokat szerződésben rögzítjük, így az adattulajdon nem csak marketingállítás.

Igen. Strukturált rekordokat nyílt formátumokban, fájlokat és dokumentumokat, metaadatokat, felhasználókat, jogosultságokat, integrációs konfigurációkat és dokumentációt. Az oldalon látható exportcsomag azt mutatja meg, milyen formában néz ki egy valódi átadás.

Ez a telepítési modelltől függ. Ha a FlowOne a saját infrastruktúrátokon fut, a működő rendszer és az adatok akkor is nálatok maradnak, ha velünk bármi történik. FlowOne által menedzselt infrastruktúrán a szerződés biztosítja a folytonosságot: dokumentált exportfolyamatokkal, hozzáféréssel a mentésekhez, átállási támogatással, előre rögzített felmondási időszakkal és — ahol üzletileg indokolt — forráskód-letéttel.

Ez a kilépési terv egyik fő célja. Dokumentált exportformátumok, migrációs dokumentáció és előre definiált átadási folyamat segítségével egy megfelelő szakértelemmel rendelkező IT-csapat akkor is végre tudja hajtani a migrációt, ha mi nem veszünk részt benne. A kilépés járhat munkával. A jóindulatunkra nem szabad, hogy szükség legyen hozzá.

A forráskód a FlowOne szellemi tulajdona, hacsak más megállapodás — például forráskód-letét — nem születik. A te adataid, exportjaid, konfigurációid és dokumentációid nem képezik a FlowOne tulajdonát. Ezt egyértelműen kimondjuk, mert ezen a területen a homályos válasz figyelmeztető jel.

Ezt már a bevezetéskor érdemes tisztázni. A kilépési terv rögzítheti, mi exportálható, milyen időzítéssel történik az átállás, milyen migrációs segítséget nyújtunk, és mennyibe kerül az esetleges további átállási munka. Nem akkor akarunk erről először tárgyalni, amikor a kapcsolat már megromlott.

Ha egy szoftverszállító nem szívesen beszél ezekről a kérdésekről még a szerződéskötés előtt, érdemes megkérdezni, miért.

Nézd meg a GYIK válaszait

Tedd fel nekünk a legnehezebb kérdéseidet.

Feltérképezhetjük a jelenlegi környezetedet, megmutathatjuk, hol tudna a FlowOne valódi javulást hozni — és azt is elmondjuk, ha valamire valószínűleg nem ez a megfelelő rendszer.