Viens rezervēšanas dzinējs stundās un dienās balstītiem, kā arī mainīga ilguma pakalpojumiem

Kādu problēmu atrisina vienots rezervēšanas dzinējs?

Daudzas plānošanas programmatūras sistēmas sākas ar fiksētu tikšanos kalendāru, kuram vēlāk tiek pievienoti izņēmumi. Anolla izmanto pretēju pieeju: atsevišķi tiek noteikts, kas tiek rezervēts, cik ilgi tas ir nepieciešams un kādiem nosacījumiem jābūt izpildītiem. Tādējādi tiek izveidots atkārtoti lietojams vienots pamats dažādu veidu pakalpojumu uzņēmumiem.

Kāpēc kalendārs pats par sevi vēl nav rezervēšanas dzinējs?

Vienkāršs kalendārs var parādīt brīvos un aizņemtos laikus. Reālā darba vidē funkcionējošai rezervēšanas sistēmai jānosaka, ko var rezervēt, kādi resursi ir nepieciešami, kā tiek noteikts ilgums, vai vēl ir brīvas vietas un vai kāda cita rezervācija pirms apstiprināšanas nav mainījusi situāciju.

Šie lēmumi kļūst sarežģīti, ja platforma apkalpo vairāk nekā vienu uzņēmējdarbības modeli. Atsevišķa kalendāra izveide katrai kategorijai dublētu loģiku, sadrumstalotu lietotāja pieredzi un apgrūtinātu turpmāko izmaiņu pārvaldību.

Pakalpojuma kategorijai jāapraksta uzņēmuma darbības konteksts, nevis jānosaka plānošanas dzinēja robežas.

Kādi principi ļauj izmantot vienu dzinēju dažādiem pakalpojumu modeļiem?

Anolla rezervēšanas modelis sastāv no neatkarīgiem slāņiem. Katrs slānis atbild uz viena veida jautājumu, un to var izmantot atkārtoti, pievienojot jaunu nozari vai rezervēšanas scenāriju.

Kā konfigurācija nonāk pieejamības dzinējā?

Dzinējs nesāk ar nozares nosaukumu, bet gan ar izvērtējamajam rezervējumam nepieciešamajiem resursiem, plānošanas modeli un ierobežojumiem. Viena un tā pati lēmumu pieņemšanas loģika tiek izmantota gan publiski, gan administrācijas izveidotiem rezervējumiem.

Konceptuālā shēma apraksta pieejamības noteikšanas plūsmu, nevis pilnīgu Anolla iekšējo sistēmu tehnisko arhitektūru.

Kā viens un tas pats dzinējs apstrādā dažādus pakalpojumu scenārijus?

Konfigurācija mainās atkarībā no scenārija, taču pamatdzinējs vienmēr atbild uz tiem pašiem jautājumiem: kādi resursi ir nepieciešami, uz cik ilgu laiku, saskaņā ar kādiem ierobežojumiem un cik liela rezervēšanas kapacitāte vēl ir pieejama?

Kā viena un tā pati sistēma atbalsta vairāku pakalpojumu kombinācijas?

Viens rezervējums ne vienmēr nozīmē vienu pakalpojumu. Klients var vēlēties vairākus secīgus, savstarpēji saistītus pakalpojumus, un pakalpojumu sniedzējs var noteikt, kurus pakalpojumus var rezervēt atsevišķi un kurus — tikai kopā ar citu pakalpojumu.

Rezervēšanas sistēma izvēlētos pakalpojumus apstrādā kā vienotu veselumu: to ilgums, pārtraukumi, cenas un nepieciešamie resursi veido kombināciju, uz kuras pamata tiek atrasti piemēroti laiki un izveidots viens rezervējums.

Pakalpojumu kombinēšanai nav nepieciešama atsevišķa rezervēšanas sistēma. Tā pati resursu, ilguma un pieejamības loģika var novērtēt gan viena pakalpojuma, gan vairāku pakalpojumu rezervējuma piemērotību.

Kā konfigurācija nonāk līdz apstiprinātam rezervējumam?

Rezervēšanas process ievēro vienotu secību arī tad, ja lietotājam redzamais pakalpojums un plānošanas modelis atšķiras.

1. Definējiet, ko var rezervēt

   Pakalpojumu sniedzējs nosaka galveno resursu un visus papildu resursus, kas nepieciešami pakalpojuma sniegšanai.

2. Nosakiet plānošanas modeli

   Pakalpojumam tiek izmantots stundās noteikts laika intervāls, dienās noteikts periods vai ilgums, kas atkarīgs no pakalpojuma un papildu izvēlēm.

3. Piemērojiet grafikus un ierobežojumus

   Darba laiks, vietu skaits, buferlaiki, iepriekšējas paziņošanas termiņi, rezervēšanas logi un citi noteikumi ierobežo teorētisko pieejamību.

4. Atrodiet klientam parādāmās iespējas

   Sistēma atgriež tikai tos laikus vai periodus, kas pieprasījuma brīdī atbilst aktīvajai konfigurācijai.

5. Pirms apstiprināšanas vēlreiz pārbaudiet pieejamību

   Atkārtota pārbaude aizsargā pret pārklājošām izmaiņām, kas radušās izvēles procesa laikā.

Kādas īpašības nodrošina vienots rezervēšanas dzinis?

Rezultāts nenozīmē, ka visi uzņēmumi izmanto identisku konfigurāciju. Dažādas konfigurācijas var balstīties uz vienu un to pašu pārbaudīto lēmumu pieņemšanas dzini un kopīgiem pārvaldības principiem.

Ko tieši nozīmē šajā gadījuma izpētē ietvertie apgalvojumi?

Šī ir produkta gadījuma izpēte, nevis klienta pieredzes stāsts. Tajā aprakstīts Anolla pašreizējais rezervēšanas modelis, atbalstītās resursu konfigurācijas un funkcionālā lēmumu pieņemšanas plūsma. Tvēruma rādītāji raksturo platformas iespējas un nav konkrētam uzņēmumam apsolīts rezultāts.

Ierobežojumi. Elastīgs kodols nepadara visu nozaru darbplūsmas identiskas. Nozarei specifiskas prasības, individuāli pielāgotas integrācijas, fiziskās piekļuves sistēmas vai neparasti cenu noteikšanas noteikumi var prasīt papildu konfigurēšanu vai izstrādi. Pieejamības precizitāte ir atkarīga no pakalpojumu sniedzēja ievadīto grafiku, resursu un noteikumu kvalitātes.