Studija slučaja proizvoda · Arhitektura platforme
Jedan sustav za rezervacije za usluge koje se temelje na satima, danima i promjenjivom trajanju
Anolla je izgrađena oko resursa, dostupnosti i pravila, a ne prema predlošku jedne djelatnosti. Zato isti temeljni sustav može upravljati terminima, grupnim uslugama, prostorima i uslugama najma bez potrebe za izradom zasebnog softverskog proizvoda za svaki model usluge.
Ovaj tehnički pregled opisuje kako Anolla modelira različite načine raspoređivanja putem jedinstvene logike resursa i dostupnosti.
Osnovni modeli raspoređivanja: prema satima, prema danima i s promjenjivim trajanjem.
Opseg konfiguracijePodržane vrste resursa u trenutačnom konfiguracijskom modelu.
Provjerene mogućnosti platformeJedinstveni sustav za provjeru dostupnosti i sukoba.
Arhitekturno načeloKoji problem rješava jedinstveni sustav za rezervacije?
Mnogi softveri za raspoređivanje polaze od kalendara termina s fiksnim trajanjem, kojem se naknadno dodaju iznimke. Anolla se temelji na suprotnom načelu: zasebno se određuje što se rezervira, koliko je dugo potrebno i koji uvjeti moraju biti ispunjeni. Tako nastaje zajednička, višekratno upotrebljiva osnova za različite vrste uslužnih poduzeća.
Izazov
Termin može zahtijevati jednog stručnjaka na 45 minuta, usluga najma može rezervirati objekt na više dana, a grupna usluga može omogućiti više sudionika u istom terminu.
Projektna odluka
Resursi, vrijeme i ograničenja modeliraju se zasebno kako bi se dostupnost mogla izračunati na temelju višekratno upotrebljivih komponenti.
Rezultat platforme
Jedan temeljni sustav podržava različite scenarije rezervacija putem jedinstvenog modela upravljanja, dok korisničko iskustvo ostaje ujednačeno.
Zašto sam kalendar još nije mehanizam za rezervacije?
Jednostavan kalendar može prikazati slobodne i zauzete termine. Sustav rezervacija koji radi u produkcijskom okruženju mora odlučiti što se može rezervirati, koji su resursi potrebni, kako se određuje trajanje, ima li još slobodnih mjesta i je li neka druga rezervacija promijenila stanje prije potvrde.
Te odluke postaju složene kada platforma podržava više od jednog poslovnog modela. Izrada zasebnog kalendara za svaku kategoriju udvostručila bi logiku, rascjepkala korisničko iskustvo i otežala upravljanje budućim promjenama.
Termini
Zahtijevaju stručnjaka, trajanje usluge i vremenske razmake između klijenata.
Grupne usluge
Zahtijevaju upravljanje brojem mjesta umjesto isključivog prava na određeno vremensko razdoblje.
Prostorije i tereni
Mogu se rezervirati u određenim vremenskim intervalima te ovisiti o radnom vremenu i pravilima pristupa.
Objekti za najam
Mogu koristiti razdoblja temeljena na danima, termine primopredaje i višednevnu dostupnost.
Kategorija usluge trebala bi opisivati poslovni kontekst tvrtke, a ne određivati granice mehanizma za zakazivanje.
Koja načela omogućuju korištenje jednog mehanizma za različite modele usluga?
Anollin model rezervacija sastoji se od neovisnih slojeva. Svaki sloj odgovara na jednu vrstu pitanja i može se ponovno upotrijebiti pri dodavanju nove djelatnosti ili scenarija rezervacije.
01 · Struktura usmjerena na resurse
Sve što ograničava dostupnost može se tretirati kao resurs: stručnjak, prostorija, teren, oprema, stol, vozilo, uslužno mjesto ili drugi objekt koji se može rezervirati.
02 · Model zakazivanja neovisan o djelatnosti
Usluga može koristiti vremenski interval temeljen na satima, razdoblje temeljeno na danima ili promjenjivo trajanje bez zasebne arhitekture proizvoda za svaku kategoriju.
03 · Centralizirana procjena ograničenja
Rasporedi, kapacitet, vremena predaha, razdoblja za rezervaciju i preklapajuće rezervacije procjenjuju se zajedno prije ponude termina te ponovno prije potvrde.
04 · Jedan model za korisničke i administrativne procese
Javna stranica za rezervacije i administrativni alati koriste istu logiku dostupnosti, čime se smanjuje rizik od proturječnih odabira.
Kako konfiguracija ulazi u mehanizam dostupnosti?
Mehanizam ne polazi od naziva djelatnosti, već od resursa, modela raspoređivanja i ograničenja potrebnih za rezervaciju koja se procjenjuje. Ista logika odlučivanja primjenjuje se i na javne rezervacije i na rezervacije izrađene putem administracijskog sučelja.
Konfiguracijski ulazi
Mehanizam dostupnosti
Izračunaj · usporedi · provjeri
Jedinstveni mehanizam objedinjuje konfiguraciju, provjerava dostupnost i primjenjuje pravila rezervacije prije vraćanja rezultata.
Izlazi mehanizma
Konceptualni dijagram opisuje tijek odlučivanja o dostupnosti, a ne cjelokupnu tehničku arhitekturu Anollinih internih sustava.
Kako isti mehanizam obrađuje različite scenarije usluga?
Konfiguracija se mijenja ovisno o scenariju, ali osnovni mehanizam uvijek odgovara na ista pitanja: koji su resursi potrebni, koliko dugo, prema kojim ograničenjima i koliko je kapaciteta za rezervacije preostalo?
| Scenarij | Model raspoređivanja | Što mehanizam procjenjuje | Ponovno upotrebljiva logika platforme |
|---|---|---|---|
| Termin kod stručnjaka | Promjenjivo trajanje | Trajanje usluge, raspored stručnjaka, vrijeme pripreme ili čišćenja te postojeće rezervacije. | Dostupnost resursa, izračun trajanja, vrijeme prethodne najave i provjera sukoba. |
| Grupni sat | Fiksno trajanje | Raspored sata, voditelj, prostorija, ograničenje broja sudionika i broj slobodnih mjesta. | Provjera više resursa, praćenje broja mjesta, vremenski okviri za rezervaciju i pravila potvrđivanja. |
| Teren ili prostorija | Po satu | Radno vrijeme, interval rezervacije, zauzetost resursa, vrijeme pripreme i opcionalni dodaci. | Generiranje termina za rezervaciju, isključivanje preklapajućih rezervacija i prikaz dostupnosti. |
| Objekt za najam | Po danu | Datum početka i završetka, vremenski okviri za primopredaju, dostupnost objekta i preklapajuća razdoblja najma. | Provjera valjanosti razdoblja, status resursa, pravila rezervacije i konačna provjera dostupnosti. |
Kako isti sustav podržava kombinacije više usluga?
Jedna rezervacija ne mora uvijek značiti jednu uslugu. Klijent može željeti nekoliko povezanih usluga zaredom, a pružatelj usluga može odrediti koje se usluge mogu rezervirati samostalno, a koje samo zajedno s drugom uslugom.
Sustav za rezervacije odabrane usluge obrađuje kao jednu cjelinu: njihova trajanja, stanke, cijene i potrebni resursi čine kombinaciju na temelju koje se pronalaze odgovarajući termini i izrađuje jedna rezervacija.
Jedna rezervacija, više usluga
Klijent može unutar jedne rezervacije odabrati više međusobno kompatibilnih usluga bez izrade zasebnih rezervacija.
Kontrolirane kombinacije
Pružatelj usluga može odrediti koje se usluge mogu rezervirati samostalno, a koje čine kombinaciju.
Zajednički izračun dostupnosti
Dostupnost se izračunava na temelju ukupnog trajanja kombinacije, stanki i potrebnih resursa.
Kombiniranje usluga ne zahtijeva zaseban sustav za rezervacije. Ista logika resursa, trajanja i dostupnosti može procijeniti prikladnost rezervacije koja obuhvaća jednu uslugu ili više usluga.
Kako konfiguracija dovodi do potvrđene rezervacije?
Postupak rezervacije slijedi jedinstven redoslijed čak i kada se usluga prikazana korisniku i model raspoređivanja razlikuju.
Odredite što se može rezervirati
Pružatelj usluga određuje primarni resurs i sve dodatne resurse potrebne za pružanje usluge.
Odredite model raspoređivanja
Usluga upotrebljava vremenski interval određen satima, razdoblje određeno danima ili trajanje koje ovisi o usluzi i dodatnim opcijama.
Primijenite rasporede i ograničenja
Radno vrijeme, broj mjesta, vrijeme između rezervacija, rokovi prethodne najave, razdoblja dostupna za rezervaciju i druga pravila ograničavaju teoretsku dostupnost.
Pronađite opcije koje će se prikazati klijentu
Sustav vraća samo one termine ili razdoblja koji odgovaraju konfiguraciji aktivnoj u trenutku upita.
Ponovno provjerite dostupnost prije potvrde
Ponovna provjera štiti od preklapajućih promjena nastalih tijekom postupka odabira.
Koje značajke proizlaze iz zajedničkog mehanizma za rezervacije?
Rezultat nije to da sva poduzeća koriste identičnu konfiguraciju. Različite konfiguracije mogu se oslanjati na isti testirani mehanizam za donošenje odluka i zajednička načela upravljanja.
Jedinstveni model upravljanja
Korisnici upravljaju resursima, uslugama, rasporedima i pravilima putem zajedničkih pojmova.
Pravila provjere koja se mogu ponovno upotrebljavati
Provjera sukoba i ograničenja provodi se centralizirano, pa poboljšanja mogu koristiti različitim modelima usluga.
Jedinstveno korisničko iskustvo
Sastanci, prostori i usluge najma mogu slijediti poznati obrazac rezervacije čak i kada imaju različita pravila dostupnosti.
Proširiva osnova platforme
Nove kategorije resursa i kombinacije usluga mogu se dodati proširivanjem konfiguracije i pravila.
Što točno znače tvrdnje u ovoj studiji slučaja?
Ovo je studija slučaja proizvoda, a ne priča o klijentu. Opisuje Anollin trenutačni model rezervacija, podržane konfiguracije resursa i funkcionalni tijek donošenja odluka. Pokazatelji opsega opisuju mogućnosti platforme i nisu rezultat zajamčen određenom poduzeću.
Osnova mogućnosti
Trenutačna konfiguracija platforme, sustav podržanih vrsta resursa i postojeći modeli raspoređivanja.
Funkcionalni dokaz
Scenariji rezervacija koji se procjenjuju putem iste provjere dostupnosti i sukoba.
Upotreba podataka
Studija slučaja ne koristi podatke klijenata koji se mogu identificirati niti pojedinačne pokazatelje uspješnosti bilo kojeg poduzeća.
Tumačenje
Stranica prikazuje opseg platforme i mogućnost ponovne uporabe arhitekture, a ne zajamčene rezultate klijenata.
Ograničenja. Fleksibilna jezgra ne čini tijekove rada u svim djelatnostima identičnima. Zahtjevi specifični za pojedinu djelatnost, prilagođene integracije, fizički sustavi kontrole pristupa ili neuobičajena pravila određivanja cijena mogu zahtijevati dodatnu konfiguraciju ili razvoj. Točnost dostupnosti ovisi o kvaliteti rasporeda, resursa i pravila koje je unio pružatelj usluge.