Produkto atvejo analizė · Platformos architektūra
Vienas rezervavimo variklis valandinėms, dieninėms ir kintamos trukmės paslaugoms
„Anolla“ sukurta remiantis ištekliais, prieinamumu ir taisyklėmis, o ne vienos veiklos srities šablonu. Todėl tas pats pagrindinis variklis gali valdyti susitikimus, grupines paslaugas, patalpas ir nuomos paslaugas, nekuriant atskiro programinės įrangos produkto kiekvienam paslaugų modeliui.
Šioje techninėje apžvalgoje aprašoma, kaip „Anolla“ modeliuoja skirtingus planavimo būdus, pasitelkdama bendrą išteklių ir prieinamumo logiką.
Pagrindiniai planavimo modeliai: valandinis, dieninis ir kintamos trukmės.
Konfigūracijos apimtisDabartiniame konfigūracijos modelyje palaikomi išteklių tipai.
Patikrintos platformos galimybėsBendras prieinamumo ir konfliktų tikrinimo variklis.
Architektūros principasKokią problemą sprendžia bendras rezervavimo variklis?
Daugelis planavimo programinės įrangos sprendimų pradedami kurti nuo fiksuoto susitikimų kalendoriaus, prie kurio vėliau pridedamos išimtys. „Anolla“ vadovaujasi priešingu principu: atskirai nustatoma, kas rezervuojama, kiek laiko to reikia ir kokios sąlygos turi būti įvykdytos. Taip sukuriamas bendras, pakartotinai naudojamas pagrindas skirtingų tipų paslaugų įmonėms.
Iššūkis
Susitikimui gali reikėti vieno specialisto 45 minutėms, nuomos paslaugai – rezervuoti objektą kelioms dienoms, o grupinė paslauga gali leisti tuo pačiu metu dalyvauti keliems dalyviams.
Projektavimo sprendimas
Ištekliai, laikas ir apribojimai modeliuojami atskirai, kad prieinamumą būtų galima apskaičiuoti remiantis pakartotinai naudojamais komponentais.
Platformos rezultatas
Vienas pagrindinis variklis palaiko skirtingus rezervavimo scenarijus per bendrą valdymo modelį, o klientų patirtis išlieka vientisa.
Kodėl vien kalendorius dar nėra rezervavimo variklis?
Paprastas kalendorius gali rodyti laisvą ir užimtą laiką. Realioje aplinkoje veikianti rezervavimo sistema turi nuspręsti, ką galima rezervuoti, kokių išteklių reikia, kaip nustatoma trukmė, ar dar yra laisvų vietų ir ar prieš patvirtinimą kita rezervacija nepakeitė situacijos.
Šie sprendimai tampa sudėtingi, kai platforma aptarnauja daugiau nei vieną verslo modelį. Kiekvienai kategorijai sukūrus atskirą kalendorių, būtų dubliuojama logika, skaidoma naudotojo patirtis ir apsunkinamas būsimų pakeitimų valdymas.
Susitikimai
Reikia specialisto, nustatytos paslaugos trukmės ir buferinio laiko tarp klientų.
Grupinės paslaugos
Reikia valdyti vietų skaičių, o ne suteikti išskirtinę teisę į vieną laiko intervalą.
Patalpos ir aikštelės
Gali būti rezervuojamos nustatytais intervalais ir priklausyti nuo darbo laiko bei prieigos taisyklių.
Nuomojami objektai
Gali būti naudojami dienomis pagrįsti laikotarpiai, perdavimo laiko intervalai ir kelių dienų prieinamumas.
Paslaugos kategorija turėtų apibūdinti įmonės veiklos kontekstą, o ne nustatyti planavimo variklio ribas.
Kokie principai leidžia naudoti vieną variklį skirtingiems paslaugų modeliams?
„Anolla“ rezervavimo modelį sudaro nepriklausomi sluoksniai. Kiekvienas sluoksnis atsako į vieno tipo klausimą ir gali būti pakartotinai naudojamas pridedant naują sritį ar rezervavimo scenarijų.
01 · Į išteklius orientuota struktūra
Viskas, kas riboja prieinamumą, gali būti laikoma ištekliumi: specialistu, patalpa, aikštele, įranga, stalu, transporto priemone, aptarnavimo vieta ar kitu rezervuojamu objektu.
02 · Nuo srities nepriklausomas planavimo modelis
Paslaugai gali būti taikomas valandomis pagrįstas laiko intervalas, dienomis pagrįstas laikotarpis arba kintama trukmė, nekuriant atskiros produkto architektūros kiekvienai kategorijai.
03 · Centralizuotas apribojimų vertinimas
Tvarkaraščiai, vietų skaičius, buferinis laikas, rezervavimo laikotarpiai ir persidengiančios rezervacijos įvertinami kartu prieš pasiūlant laiką ir dar kartą prieš patvirtinant.
04 · Vienas modelis klientų ir administravimo procesuose
Viešas rezervavimo puslapis ir administravimo įrankiai naudoja tą pačią prieinamumo logiką, todėl sumažėja prieštaringų pasirinkimų rizika.
Kaip konfigūracija perduodama prieinamumo varikliui?
Variklis pradeda ne nuo veiklos srities pavadinimo, o nuo vertinamai rezervacijai reikalingų išteklių, planavimo modelio ir apribojimų. Ta pati sprendimų priėmimo logika taikoma tiek viešoms, tiek administravimo aplinkoje sukurtoms rezervacijoms.
Konfigūracijos įvestys
Prieinamumo variklis
Apskaičiuoti · palyginti · patikrinti
Bendras variklis sujungia konfigūraciją, patikrina prieinamumą ir pritaiko rezervavimo taisykles prieš pateikdamas rezultatą.
Variklio išvestys
Koncepcinė schema apibūdina prieinamumo nustatymo eigą, o ne visą techninę „Anolla“ vidinių sistemų architektūrą.
Kaip tas pats variklis naudojamas skirtinguose paslaugų scenarijuose?
Konfigūracija skiriasi priklausomai nuo scenarijaus, tačiau pagrindinis variklis visada atsako į tuos pačius klausimus: kokių išteklių reikia, kuriam laikui, pagal kokius apribojimus ir kiek rezervavimo pajėgumo dar liko?
| Scenarijus | Planavimo modelis | Ką vertina variklis | Pakartotinai naudojama platformos logika |
|---|---|---|---|
| Specialisto konsultacija | Kintama trukmė | Paslaugos trukmė, specialisto darbo grafikas, pasiruošimo arba sutvarkymo laikas ir esamos rezervacijos. | Išteklių prieinamumas, trukmės apskaičiavimas, išankstinio rezervavimo terminas ir konfliktų patikra. |
| Grupinis užsiėmimas | Fiksuota trukmė | Užsiėmimo tvarkaraštis, instruktorius, patalpa, dalyvių skaičiaus riba ir laisvų vietų skaičius. | Kelių išteklių patikra, vietų skaičiaus stebėjimas, rezervavimo laikotarpiai ir patvirtinimo taisyklės. |
| Aikštelė arba patalpa | Valandinis | Darbo laikas, rezervavimo intervalas, išteklių užimtumas, pasiruošimo laikas ir pasirenkami priedai. | Rezervuojamų laiko intervalų generavimas, sutampančių rezervacijų atmetimas ir prieinamumo rodymas. |
| Nuomos objektas | Dieninis | Pradžios ir pabaigos datos, perdavimo laiko intervalai, objekto prieinamumas ir sutampantys nuomos laikotarpiai. | Laikotarpio patvirtinimas, išteklių būsena, rezervavimo taisyklės ir galutinė prieinamumo patikra. |
Kaip ta pati sistema palaiko kelių paslaugų derinius?
Viena rezervacija ne visada turi reikšti vieną paslaugą. Klientas gali pageidauti kelių susijusių paslaugų iš eilės, o paslaugų teikėjas gali nustatyti, kurias paslaugas galima rezervuoti atskirai, o kurias – tik kartu su kita paslauga.
Rezervavimo sistemoje pasirinktos paslaugos laikomos viena visuma: jų trukmė, pertraukos, kainos ir reikalingi ištekliai sudaro derinį, pagal kurį randamas tinkamas laikas ir sukuriama viena rezervacija.
Viena rezervacija, kelios paslaugos
Klientas vienoje rezervacijoje gali pasirinkti kelias tarpusavyje suderinamas paslaugas, nekurdamas atskirų rezervacijų.
Kontroliuojami deriniai
Paslaugų teikėjas gali nustatyti, kurias paslaugas galima rezervuoti atskirai, o kurios sudaro derinį.
Bendras prieinamumo apskaičiavimas
Prieinamumas apskaičiuojamas pagal bendrą derinio trukmę, pertraukas ir reikalingus išteklius.
Paslaugoms derinti nereikia atskiros rezervavimo sistemos. Ta pati išteklių, trukmės ir prieinamumo logika gali įvertinti tiek vienos paslaugos, tiek iš kelių paslaugų sudarytos rezervacijos tinkamumą.
Kaip konfigūracija virsta patvirtinta rezervacija?
Rezervavimo eiga vyksta ta pačia seka net ir tada, kai naudotojui rodoma paslauga ir planavimo modelis skiriasi.
Apibrėžkite, ką galima rezervuoti
Paslaugų teikėjas nustato pagrindinį išteklių ir visus papildomus išteklius, reikalingus paslaugai suteikti.
Nustatykite planavimo modelį
Paslaugai taikomas valandomis skaičiuojamas laiko intervalas, dienomis skaičiuojamas laikotarpis arba nuo paslaugos ir papildomų pasirinkimų priklausanti trukmė.
Taikykite grafikus ir apribojimus
Darbo laikas, vietų skaičius, buferinis laikas, išankstinio pranešimo terminai, rezervavimo laikotarpiai ir kitos taisyklės riboja teorinį prieinamumą.
Raskite klientui rodomus pasirinkimus
Sistema pateikia tik tuos laikus ar laikotarpius, kurie užklausos metu atitinka aktyvią konfigūraciją.
Prieš patvirtindami dar kartą patikrinkite prieinamumą
Pakartotinis patikrinimas apsaugo nuo persidengiančių pakeitimų, atsiradusių pasirinkimo metu.
Kokias savybes užtikrina vieningas rezervavimo mechanizmas?
Rezultatas nereiškia, kad visos įmonės naudoja identišką konfigūraciją. Skirtingos konfigūracijos gali būti grindžiamos tuo pačiu išbandytu sprendimų priėmimo mechanizmu ir bendrais valdymo principais.
Bendras valdymo modelis
Naudotojai valdo išteklius, paslaugas, grafikus ir taisykles naudodami bendras sąvokas.
Pakartotinai naudojamos tikrinimo taisyklės
Konfliktų tikrinimas ir apribojimai valdomi centralizuotai, todėl patobulinimais gali naudotis keli paslaugų modeliai.
Vieninga kliento patirtis
Susitikimams, patalpoms ir nuomos paslaugoms galima taikyti įprastą rezervavimo procesą net ir esant skirtingoms prieinamumo taisyklėms.
Plečiamas platformos pagrindas
Naujas išteklių kategorijas ir paslaugų derinius galima pridėti išplečiant konfigūraciją ir taisykles.
Ką tiksliai reiškia šios atvejo analizės teiginiai?
Tai produkto atvejo analizė, o ne kliento sėkmės istorija. Joje aprašomas dabartinis „Anolla“ rezervavimo modelis, palaikomos išteklių konfigūracijos ir funkcinis sprendimų priėmimo procesas. Aprėpties rodikliai apibūdina platformos galimybes ir nėra konkrečiai įmonei pažadėtas rezultatas.
Galimybių pagrindas
Dabartinė platformos konfigūracija, palaikomų išteklių tipų sistema ir esami planavimo modeliai.
Funkcinis įrodymas
Rezervavimo scenarijai, vertinami taikant tą pačią prieinamumo ir konfliktų patikrą.
Duomenų naudojimas
Atvejo analizėje nenaudojami asmens tapatybę leidžiantys nustatyti klientų duomenys ar kurios nors įmonės individualūs veiklos rodikliai.
Interpretacija
Puslapyje parodoma platformos aprėptis ir galimybė pakartotinai naudoti jos architektūrą, o ne garantuojami klientų rezultatai.
Apribojimai. Lankstus branduolys nepadaro visų sektorių darbo procesų identiškų. Konkrečiam sektoriui taikomi reikalavimai, individualiai pritaikytos integracijos, fizinės prieigos sistemos ar neįprastos kainodaros taisyklės gali pareikalauti papildomo konfigūravimo arba programavimo darbų. Prieinamumo tikslumas priklauso nuo paslaugų teikėjo įvestų tvarkaraščių, išteklių ir taisyklių kokybės.