Valik sõltub teenusest või ressursist
Saadavad ajad võivad sõltuda asukohast, spetsialistist, kestusest, seadmest või muust kinnitatud reeglist, mida peab kasutajale arusaadavalt näitama.
Broneerimissüsteemi arendus
Broneerimissüsteem, mis seob kliendi valiku ja igapäevase halduse.
Arendame broneerimisvooge teenustele, aegadele või ressurssidele, kui valmis kalender ei kata valikureegleid, rolle, teavitusi või ühendusi. Kliendivaade ja haldaja töö kavandatakse ühe protsessina.
Räägime projektistMida broneerimine peab lahendama
Haldaja vajab kontrollitavat töölauda
Broneeringu kinnitamine, muutmine, tühistamine ja märkused vajavad rolle, ajalugu ning ühist vaadet, mitte ainult kalendrikirjet.
Voog ühendub teiste teenustega
Kokkulepitud makse, CRM, kalender, e-post või muu süsteem vajab idempotentset andmevahetust, vigade nähtavust ja testitavat piiri.
Saadavus, olek ja erandid enne ekraane
Saadavuse allikas peab olema üks
Lepime kokku, kus tekib vaba aeg või ressurss ning kuidas välditakse sama valiku topeltkasutust. Väline kalender ei ole automaatselt broneerimisloogika omanik.
Broneeringul on elutsükkel
Päring, ootel, kinnitatud, muudetud ja tühistatud võivad vajada erinevaid tegevusi ja teavitusi. Kasutatavad olekud sõltuvad päris teenindusprotsessist.
Erandid kuuluvad põhivoogu
Ajavöönd, paus, puuduv kinnitus, hilinenud ühendus ja korduv päring kontrollitakse seal, kus nende mõju on kriitiline.
Broneerimislahenduse võimalik ulatus
Broneerimislahenduse võimalik ulatus
- Teenuse, ressursi ja saadavuse mudel
- Kliendi valiku- ja kinnitusvoog
- Haldusvaade, rollid ja olekud
- Kokkulepitud teavitused ja ühendused
- Tühistamise, muutmise ja veajuhtumid
Mida vajame sisuliseks kaardistuseks
Tänane töö ja vastutajad
Kirjeldage, kes lahendust kasutab, millised tegevused tehakse täna käsitsi või eri tööriistades ning kes vastutab põhiandmete ja otsuste eest. Olemasolevad ekraanid, protsessijoonis ja näidisjuhtumid aitavad eristada igapäevast tööd harvadest eranditest.
Andmed, ühendused ja piirangud
Koondame kasutatavad süsteemid, andmeallikad, ligipääsureeglid, keeled ja vajalikud liidestused. Kui dokumentatsioon või testkeskkond puudub, märgime selle sõltuvusena ega eelda välise süsteemi käitumist.
Edu ja vastuvõtu tunnused
Lepime kokku, milline lõpetatav tegevus peab esimeses etapis töötama, kuidas tulemust kontrollitakse ning millised vead või katkestused peavad olema nähtavad. Mõõdik lisatakse ainult siis, kui selle lähteandmed ja arvutusviis on teada.
Kuidas töö liigub otsusest toimiva etapini
Kaardistus
Vaatame koos läbi kasutajad, eesmärgi, tänase töö, andmed, sõltuvused ja kriitilised erandid. Tulemuseks on kontrollitav ulatus, mitte oletustel põhinev funktsioonide nimekiri.
Struktuur ja prototüüp
Seome põhitegevused, olekud ja infoarhitektuuri ekraanideks või tehniliseks vooskeemiks. Enne arendust kontrollime, et kasutaja ja haldaja jõuavad mõlemad lõpetatava tulemuseni.
Arendus ja ühendused
Teostame kokkulepitud liidese, serveripoolse loogika ning integratsioonid väikeste kontrollitavate osadena. Vigade käsitlemine, õigused ja logitavad sündmused kuuluvad sama etapi vastuvõttu.
Testimine ja üleandmine
Kontrollime tavavoogu, olulisemaid erandeid, eri seadmeid ja kokkulepitud andmevahetust. Enne käivitamist fikseerime teadaolevad piirangud, vastutajad, jälgimise ja tagasipöördumise võimaluse.
Piirid, mis peavad enne teostust selged olema
Piirid, mis peavad enne teostust selged olema
- Esimese etapi kasutajad, rollid ja lõpetatav põhitegevus
- Põhiandmete omanikud, kohustuslikud väljad ja säilitamise vajadus
- Kokkulepitud välised süsteemid, ligipääsud ja testimisvõimalus
- Kriitilised erandid, veateated, õigused ja auditit vajavad sündmused
- Vastuvõtukontroll, käivitamise vastutus ja järgmise etapi nimekiri
Käivitamine, jälgimine ja edasine vastutus
Üleandmine ei piirdu valmis ekraanidega. Koondame kokkulepitud funktsioonid, ligipääsu- ja haldusjuhised, väliste ühenduste sõltuvused, teadaolevad piirangud ning kontrollid, millega meeskond saab lahenduse tööd jälgida. Käivitamise viis, andmete ülemineku hetk, tagasipöördumise võimalus ja järgmise etapi prioriteedid lepitakse kokku vastavalt süsteemi riskile; neid ei esitata enne kaardistust kindla lubadusena.
Tõendatud remondibroneering
iProff
iProffi avalikus lahenduses kujundas ja arendas GoMedia mitmekeelse teekonna seadme, mudeli ja remondi valikust teenindusviisi, aja, kontaktandmete ning päringu ülevaateni.
Tutvu projektiga
Küsimused broneerimissüsteemi kohta
Kas süsteem saab näidata vabu aegu?
Jah, kui saadavuse allikas, kestused, ressursid ja blokeerimisreeglid on teada. Reegleid ei tuletata ainult kalendrivaate järgi.
Kas klient saab broneeringut muuta?
See sõltub teenuse reeglitest. Määrame lubatud ajaakna, autentimise, mõju saadavusele ja vajaliku teavituse.
Kas makse saab lisada?
Kokkulepitud makseteenuse saab voogu liidestada eraldi ulatusena koos õnnestumise, katkestuse, korduse ja tagasimakse piiridega.
Kas lahendus sobib mitmele asukohale?
Sobib, kui asukohad, ressursid, teenused, keeled ja haldusvastutus on andmemudelis eraldi kirjeldatud.
Broneerimissüsteem, mis seob kliendi valiku ja igapäevase halduse.
Kirjeldage lühidalt eesmärki, kasutajaid, tänast lahendust ja funktsioone, mida vajate. Esimeses vestluses täpsustame küsimused ning lepime kokku, millist kaardistust on enne pakkumist vaja.