Klientu portāls pakalpojumu uzņēmumam: ko iekļaut pirmajā versijā

Klientu portāla pirmajā versijā jāiekļauj mazākais funkciju kopums, ar kuru klients var patstāvīgi izpildīt vienu pilnu un bieži atkārtotu uzdevumu. Parasti tas nozīmē drošu pieslēgšanos, savu pakalpojumu vai lietu pārskatu, dokumentu apmaiņu, strukturētu pieprasījumu iesniegšanu, statusa redzamību un saprotamus paziņojumus. Uzņēmuma pusē vajadzīga lietotāju, tiesību, satura un darbību administrēšana.

Pirmās versijas mērķis nav pārnest portālā visu klientu apkalpošanu. Tai jāpierāda, ka konkrēta darba plūsma kļūst klientam saprotamāka un uzņēmumam — vieglāk pārvaldāma, neradot nepieņemamu drošības vai uzturēšanas risku.

Kas ir klientu portāls un kādu problēmu tam jāatrisina

Klientu portāls ir autentificēta digitāla vide, kurā klients redz tieši savai organizācijai vai kontam paredzētu informāciju un veic atļautās darbības. Tas atšķiras no publiskas mājaslapas: portālā ir lietotāju identitātes, piekļuves tiesības, ar konkrētu klientu saistīti dati un darbību vēsture.

Pakalpojumu uzņēmumā portāls var aizstāt daļu e-pastu, failu pārsūtīšanas un atkārtotu jautājumu par darba statusu. Tomēr portāls pats par sevi nesakārto neskaidru procesu. Ja darbinieki atšķirīgi nosauc statusus, nav zināms atbildīgais vai dokumenti tiek glabāti vairākās vietās, programmatūra šo neskaidrību tikai padarīs redzamāku.

Tāpēc pirms funkciju izvēles jāformulē viena konkrēta problēma, piemēram: “Klients nevar vienuviet iesniegt uzdevumu, pievienot nepieciešamos dokumentus un redzēt, kas notiks tālāk.” Šis formulējums dod robežu pirmajai versijai un palīdz atteikt funkcijas, kuras neatrisina izvēlēto problēmu.

Sāciet ar vienu pilnu klienta darba scenāriju

Funkciju saraksta vietā aprakstiet vienu ceļu no klienta vajadzības līdz izmantojamam rezultātam. Piemēram:

1. Klienta administrators uzaicina kolēģi un piešķir viņam lomu.
2. Lietotājs pieslēdzas un izvēlas vajadzīgo pakalpojumu.
3. Viņš aizpilda strukturētu pieteikumu un pievieno dokumentus.
4. Uzņēmuma darbinieks pārbauda informāciju un vajadzības gadījumā pieprasa precizējumu.
5. Klients portālā redz statusu, termiņu vai nākamo nepieciešamo darbību.
6. Pēc darba pabeigšanas klients saņem rezultātu un saglabājas darbību vēsture.

Ja kāds posms notiek ārpus portāla, tas jānosauc apzināti. Piemēram, pirmajā versijā speciālists var apstrādāt pieteikumu esošajā iekšējā sistēmā, bet klientam portālā tiek parādīts tikai pārbaudīts statuss. Tas ir pieņemami, ja datu nodošana ir uzticama un darbiniekam nav informācija manuāli jāievada vairākās vietās.

Klientu portāla pirmās versijas kodols

Konkrētais tvērums ir atkarīgs no pakalpojuma, taču šādu komplektu var izmantot kā sākuma modeli.

Svarīgākais ir nevis komponentu skaits, bet to sasaiste. Statusa lauks nav vērtīgs, ja tas netiek atjaunināts. Failu sadaļa nepalīdz, ja nav redzams, ar kuru pieteikumu dokuments saistīts. Paziņojums rada apjukumu, ja tajā nav saprotama nākamā darbība.

Lomas un piekļuves jādefinē pirms ekrānu dizaina

Daudzos pakalpojumu uzņēmumos ar vienu lomu “klients” nepietiek. Klienta organizācijā var būt administrators, iesniedzējs, skatītājs un finanšu kontaktpersona. Uzņēmuma pusē var būt speciālists, klientu vadītājs un sistēmas administrators.

Katrai lomai jāatbild uz četriem jautājumiem: kādus ierakstus tā redz, kādas darbības drīkst veikt, kādus failus drīkst lejupielādēt un vai drīkst uzaicināt citus lietotājus. Tiesības vēlams piešķirt pēc mazāko nepieciešamo privilēģiju principa, nevis sākumā atvērt visu un vēlāk mēģināt piekļuvi ierobežot.

Jāpārbauda arī klientu savstarpēja datu izolācija. Nepietiek paslēpt citas organizācijas ierakstu saskarnē; piekļuves pārbaudei jānotiek servera pusē pie katra aizsargāta pieprasījuma. Administratīvajām un paaugstināta riska lomām jāapsver daudzfaktoru autentifikācija.

Drošība un privātums nav atliekama otrās versijas funkcija

Ja portālā apstrādā personas datus, jāievēro Vispārīgās datu aizsardzības regulas principi. Regulas 5. pants ietver datu minimizēšanu un glabāšanas ierobežojumu, 25. pants paredz datu aizsardzību pēc noklusējuma un projektēšanas stadijā, bet 32. pants prasa riskam atbilstošus tehniskus un organizatoriskus pasākumus. Precīzās prasības jāvērtē pēc apstrādāto datu veida, riska, uzņēmuma lomas un piemērojamā regulējuma; portāla izstrāde pati par sevi nenodrošina juridisku atbilstību.

Pirmajā versijā jāparedz vismaz:

•      šifrēts savienojums un droša paroļu apstrāde;
•      sesiju termiņi, atteikšanās un drošs paroles atjaunošanas process;
•      aizsardzība pret automatizētiem pieslēgšanās mēģinājumiem;
•      failu tipu, izmēra un piekļuves pārbaudes;
•      servera puses autorizācija katrai aizsargātai darbībai;
•      būtisko administratīvo un datu darbību žurnāls;
•      rezerves kopiju, atjaunošanas un incidentu apstrādes kārtība;
•      lietotāju slēgšanas un datu glabāšanas termiņu process.

OWASP Application Security Verification Standard var izmantot kā strukturētu pamatu tīmekļa lietotnes drošības prasību un pārbaužu formulēšanai. Tas neaizstāj konkrētās sistēmas draudu modelēšanu, konfigurācijas pārbaudi vai profesionālu drošības testēšanu.

Pieejamība uzlabo arī ikdienas lietojamību

Portāla pamatdarbībām jābūt izpildāmām ar tastatūru, laukiem vajadzīgas saprotamas etiķetes, fokusam jābūt redzamam, bet kļūdas jāizskaidro tekstā, nevis tikai ar krāsu. Dokumentiem un paziņojumiem jābūt saprotami nosauktiem. W3C WCAG 2.2 ir praktisks atskaites punkts digitālās pieejamības prasību definēšanai.

Pieejamību ir dārgāk labot pēc tam, kad komponenti un dizaina sistēma jau nostiprināti. Tāpēc pirmās versijas pieņemšanas kritērijos jāiekļauj svarīgākie lietotāju ceļi, nevis jāatstāj pieejamība kā nenoteikts nākotnes uzlabojums.

Ko parasti atlikt uz vēlāku versiju

Pirmajā laidienā parasti nav vajadzīga atsevišķa mobilā lietotne, reāllaika čats, mākslīgā intelekta asistents, sarežģīts atskaišu konstruktors, pilna norēķinu sistēma vai integrācija ar katru uzņēmuma rīku. Šīm funkcijām ir ne tikai izstrādes, bet arī piekļuves, datu kvalitātes, atbalsta un uzturēšanas izmaksas.

Atlikšana nav universāls aizliegums. Ja maksājums ir obligāts, lai pabeigtu izvēlēto scenāriju, norēķini ir kodola funkcija. Ja klientam jāsaņem atbilde dažu minūšu laikā un tas ir pakalpojuma būtisks nosacījums, ziņapmaiņa var būt nepieciešama. Kritērijs ir funkcijas nozīme pilnā darba scenārijā, nevis tās popularitāte citos portālos.

Kā izvēlēties funkcijas, ja vēlmju ir par daudz

Katru funkciju novērtējiet pēc četriem jautājumiem:

1. Vai bez tās klients var pabeigt izvēlēto uzdevumu?
2. Vai tā samazina konkrētu manuālu darbību vai kļūdu avotu?
3. Vai uzņēmums spēs uzturēt funkcijai vajadzīgos datus un atbildēt uz izņēmumiem?
4. Kāds ir drošības, juridiskais un integrācijas risks?

Funkcija ar augstu klienta vērtību, bet neskaidru datu avotu nav gatava izstrādei. Vispirms jānosaka datu īpašnieks un atjaunošanas process. Savukārt vienkārša funkcija, kas neietekmē klienta mērķi vai uzņēmuma darbu, nav jāiekļauj tikai tāpēc, ka to var ātri izveidot.

Lēmumu tabulā katrai funkcijai pievienojiet pamatojumu, īpašnieku, atkarības un pārbaudāmu pieņemšanas kritēriju. Tas samazina risku, ka “obligāta” patiesībā nozīmē tikai kādas iesaistītās puses personīgu vēlmi.

Integrācijas un tehniskā robeža

Portālam nav obligāti jākļūst par galveno sistēmu visiem uzņēmuma datiem. Tam jāparāda klientam uzticama informācija un jānogādā ievadītie dati uz vietu, kur notiek darbs. Pirms integrācijas jānosaka, kura sistēma ir katra datu veida autoritatīvais avots, kas drīkst datus mainīt un kas notiek kļūdas gadījumā.

Pirmajā versijā var pietikt ar ierobežotu API integrāciju, kontrolētu datu importu vai operatora apstiprinātu sinhronizāciju. Izvēle ir atkarīga no apjoma, aktualitātes prasības un kļūdas sekām. Jāparedz dublikātu novēršana, atkārtota apstrāde, kļūdu žurnāls un manuāls rezerves process. Klientam nedrīkst parādīt veiksmīgu iesniegšanu, ja dati faktiski nav saglabāti vai nodoti tālāk.

Testēšana un pakāpeniska palaišana

Pirms palaišanas jāpārbauda ne tikai atsevišķas pogas, bet pilni scenāriji katrai lomai. Testos jāiekļauj nepareiza parole, beigusies sesija, trūkstošs obligātais lauks, neatļauts fails, citas organizācijas ieraksta adrese, neveiksmīga integrācija un paziņojuma atkārtota nosūtīšana.

Lietojamības pārbaudē dalībniekam dod uzdevumu, nevis instrukciju, uz kuras pogas jāspiež. Jāvēro, vai viņš saprot statusus, atrod dokumentus un zina nākamo darbību. Ja uzdevumu var izpildīt tikai ar izstrādes komandas skaidrojumu, saskarne vēl nav pašapkalpošanās risinājums.

Drošāka ir pakāpeniska palaišana ierobežotai klientu grupai ar skaidru atbalsta kanālu un iespēju kritiskā situācijā izmantot iepriekšējo procesu. Rezerves process nedrīkst kļūt par pastāvīgu paralēlu sistēmu, tāpēc jāreģistrē, kāpēc tas izmantots un kas portālā jālabo.

Kā izmērīt, vai pirmā versija ir izdevusies

Pirms izstrādes fiksējiet sākuma situāciju un izvēlieties dažus rādītājus, kas saistīti ar portāla mērķi:

•      uzaicināto klientu daļa, kas veikusi mērķa darbību;
•      patstāvīgi pabeigto pieteikumu īpatsvars;
•      nepilnīgu vai precizējamu pieteikumu skaits;
•      laiks no iesniegšanas līdz nākamajam procesa posmam;
•      ar statusu vai dokumentu atrašanu saistīto atbalsta pieprasījumu skaits;
•      neveiksmīgu pieslēgšanos, integrāciju un augšupielāžu kļūdu biežums.

Nav viena universāla laba rezultāta. Salīdziniet vienādi definētus periodus un atsevišķi vērtējiet tehniskas kļūdas, lietojamības problēmas un procesa kavējumus. Zema izmantošana var nozīmēt ne tikai sliktu portālu, bet arī neskaidru uzaicināšanu, klientam nevajadzīgu scenāriju vai darbinieku turpinātu paralēlu saziņu e-pastā.

Ierobežojumi un galvenie riski

Klientu portāls nav piemērotākais risinājums ļoti retam, katru reizi pilnīgi atšķirīgam procesam, ja strukturēšana rada vairāk darba nekā dod ieguvumu. Tas arī neaizstāj personisku komunikāciju situācijās, kur vajadzīga konsultācija, saruna par neskaidru vajadzību vai sensitīvs lēmums.

Biežākie riski ir pārāk plašs sākotnējais tvērums, nekvalitatīvi avota dati, neskaidras lomas, nepārbaudīta klientu datu izolācija, pārmērīgi paziņojumi un administrēšanas iespēju trūkums. Vēl viens risks ir “ēnu process”: portāls pastāv, bet darbinieki turpina uzturēt patieso statusu izklājlapā vai e-pastā. To novērš skaidrs datu īpašnieks, darba noteikumi un mērījumi pēc palaišanas.

Pirmās versijas kontrolsaraksts

Pirms izstrādes apstipriniet, ka:

•      ir nosaukts viens pilns klienta scenārijs un tā robežas;
•      katram datu veidam zināms avots un īpašnieks;
•      definētas klienta un uzņēmuma lomas;
•      aprakstītas servera puses piekļuves pārbaudes;
•      paziņojumiem ir konkrēts notikums un nākamā darbība;
•      paredzēta kļūdu, rezerves kopiju un manuālu izņēmumu apstrāde;
•      galvenie scenāriji ir pārbaudāmi ar pieņemšanas kritērijiem;
•      noteikti sākuma rādītāji un rezultāta mērījumi;
•      ir atbildīgais par portālu pēc palaišanas.

Labs pirmās versijas tvērums nav garš funkciju saraksts. Tas ir viens drošs, saprotams un izmērāms klienta darba ceļš, kuru uzņēmums spēj uzturēt arī pēc izstrādes projekta beigām. Kad šis ceļš darbojas, nākamo versiju prioritātes var balstīt lietošanas datos un reālos šķēršļos, nevis pieņēmumos.