Posts Tagged ‘analītiķu vakariņas’

24.04.2013 Analītiķu vakariņu „minūtītes” : datu migrācija


24.aprīlī norisinājās tradicionālās Analītiķu vakariņas, šoreiz tēma – datu migrācija, par kuru stāstīja Valdis Prodnieks no Exigen Services Latvia. Prezentācija ir skatāma šeit http://www.slideshare.net/ksenijalace/datu-migrcija

Saruna izvērtās interesanta – jo, plānojot un veicot datu migrāciju, svarīgi aizdomāties par procesu kopumā. Tā kā problēmu parasti ir daudz, noder arī sajūta, ka arī citiem tā gadās… :-) Par to šīs manas piezīmes.

 Kāpēc veci dati jāmigrē?

  • Likumdošana pieprasa noteiktu glabāšanas laiku,
  • Ilgtermiņa līgumi, piemēram, kredīts uz 50 gadiem,
  • Uzņēmums grib ilggadēju vēsturi, piemēram, visu savākto statistiku par apdrošināšanas gadījumiem,
  • citi iemesli.

Tomēr – ja ir iespēja vecos datus nemigrēt, parasti nemigrē.

Mīti

(Valdis minēja vairākus, bet šie man īpaši patika – kaut kur tā kā dzirdēti…):

  • Mani dati ir kārtībā!
  • Man ir dokumentācija, kurā aprakstīts, kā dati jāvalidē!
  • Ja sistēma māk strādāt ar jaunajiem, gan jau mācēs arī ar vecajiem!

Piezīmes par pārrunāto, kas mani īpaši uzrunāja:

Datu migrācija ir tikai daļa no lielāka procesa – IS vai IS versijas maiņas, procesu maiņa, platformas maiņa, uzņēmuma īpašnieku un/vai kultūras maiņas u.tml. Datu migrācija pati par sevi nenes biznesa labumu un faktiski vēlme ir, lai pats process un dati pēc pārmigrēšanas nenestu pārāk lielus zaudējums. Triks: nevis migrācija, bet modernizācija.

Migrācija var būt tāds process, kuram otra mēģinājuma var nebūt. Nepietiek, ka datus var dabūt ārā no vecās sistēmas – ir jābūt jaunajai sistēmai, kura šos datus spēj paņemt pretī. Nav ieteicams migrēt uz tukšu vietu. Klausoties Valda pieredzi, domāju, ka dažas situācijas mazāk pieredzējušiem bukiem pat prātā neienāktu, piemēram, ka vecajā platformā skaitļus datubāzē glabā pretējā secībā (nevis 123,45, bet 54,321). Ja datu ir daudz, tad visticamāk, ka ielādēs pa porcijām, un jāplāno, vai un kā vecā sistēma spēs padot datus izmaiņu režīmā.

Viss sākas ar situācijas novērtēšanu – kādi dati ir un ko ar tiem domā tālāk darīt. Izvērtē situāciju un to, vai labot pirms vai pēc migrācijas. Datiem, kuru ietekme pēc migrācijas ir maza, neinvestē labošanas procesā. Dažreiz analīzes rezultātā atsakās no datu migrēšanas. Šie projekti reti kad notiek par cieto cenu, jo nav zināms, kas izlīdīs.

Bez klienta iesaistīšanās un bez biznesa zinātājiem migrācija nav iespējama. Ir veco datu tīrīšanas, kuras var veikt IT cilvēki un ir tīrīšanas, kuras var veikt tikai biznesa cilvēki. Svarīgi nodrošināt, lai nenoslogotu šos cilvēkus ar pretējiem jautājumiem. IT cilvēki, piemēram, risina to, ka senāk plaši lietoja hārdkodēšanu [un, tipiski, mazdokumentētu]. Jaunā pieeja ir konfigurējams parametrs. Migrējot – aijaijai, cik ņemšanās ir IT cilvēkiem. Biznesa cilvēki risina, piemēram, to, vai sen atpakaļ veidotas atļaujas, kurām nav aizpildīti numuri un derīguma termiņi, vispār ir uzskatāmas par derīgām.

Jārēķinās, ka:

  • ikvienā sistēmā vienmēr būs lietas, kuras neviens vairs nespēj izskaidrot, kāpēc ir tā kā ir,
  • migrācija vienmēr aizņems vairāk laika nekā plānots.

Pamatproblēma praktiski vienmēr ir: datu trūkst. Cēloņi – visdažādākie, sākot ar to, ka līgumiem, kurus slēdza 10 gadus atpakaļ, deklarēto adresi neprasīja, turpinot ar radošām pieejām problēmu risināšanai „a davai laukā „Vēlamā saziņas valoda” ierakstām adresi, jo šo lauku mēs tāpat neizmantojam, un beidzot ar kļūdām ievades programmā vai manuālām čaklo roku izmaiņām pašā datubāzē.

Dažreiz dara tā, ka jaunajā sistēma paredz citu apstrādi vecajiem datiem. Ja iespējams, vecajā sistēmā uzsāktiem procesiem ļauj nobeigties vecajā sistēmā. Ja ir iespējams, validāciju un tīrīšanu labāk veikt vecajā sistēmā.

Var lādēt pa tiešo jaunās datubāzes tabulās, var lādēt caur saskarnes API, imitējot lietotāja veiktu ievadi (ilgāks, bet jaunajiem datiem draudzīgāks).

Ja paralēli darbina veco un jauno sistēmu, par katru aspektu ir jābūt vienai galvenajai IS. Vienā brīdī būs jāpieņem lēmums, kuru izslēgt. Būtu labi, ja ir manevra iespējas.

Testēšana – nemaz necenšas visu notestēt, testē būtiskos biznesa scenārijus un datus, kurus visvairāk žēl zaudēt. Testējot visus, izmaksas par pēdējo % datu testēšanu būtu ārkārtīgi lielas. Nereti testēšana notiek uz anonimizētiem datiem.

Kāpēc mēs nerunājām par rīkiem? Tāpēc, ka to ir daudz, un rīks ir tikai rīks. Rīku darbina cilvēks, savukārt cilvēkam ir jāsaprot migrācijas būtība, mērķi un riski. Un vispār, rīki grib uzsēsties mums uz galvas, tāpēc būt pārlieku lojālam kādam rīkam ir kaitīgi.

Advertisements

20.03.2013 Analītiķu vakariņu „minūtītes” : NoSQL un Clusterpoint


Vai eksistē pasaule ārpus SQL? Par to runājām 20.03.2013 Analītiķu vakariņās. Sākām ar atmiņas atsvaidzināšanu par to, kādi datubāzu veidi ir (diemžēl, LU lektors saslima, tāpēc šī daļa bija īsāka nekā gribējās), un, lai runa nebūtu sausa, skatījām konkrētu piemēru NoSQL sistēmai. Par tādu tika izvēlēts Latvijā tapis risinājums ClusterPoint (pirms neilga laika saņēmis mūsu mērogiem iespaidīgas investīcijas – BaltCap, a leading venture investor in startups in the Baltics region, has signed a €1 million investment in Clusterpoint, an enterprise software startup created by Latvian programmers and backed by seed investors in the UK and Baltics).

Paveicās, ka varēja ierasties viens no izstrādātājiem – Gints Ernestsons, līdz ar ko vakara gaitā tika atbildēti pat vistehniskākie jautājumi (uz vakariņām šoreiz bija ieradušies neparasti daudz programmētāju).

Datubāzu veidi

Daudzi un dažādi:

  • Relāciju (SQL),
  • NewSQL (…maintain ACID and relational integrity, but are in memory (like NoSQL) and readily scalable. They support SQL syntax…),
  • Key Value Stores (…to store millions of key–value pairs…),
  • Big table/HADOOP (…liela izmēra datu failiem (gigabaiti, terabaiti. Failus vienreiz ieraksta un pēc tam nemaina, tikai daudzreiz nolasa…),
  • Document stores (…Documents inside a document-oriented database are similar, in some ways, to records or rows…) <– šajā grupā ir tālāk apskatītā Clusterpoint,
  • Object DB, Object relational DB, Graph DB, In Memory DB, Cloud DB, Desktop 4GL, Navigational, Spatial/Geo Spatial, XML, Embedded u.c.

Mums pazīstamākā ir Relāciju jeb SQL. Sākotnēji paredzēta skaitļiem un īsiem tekstiem; jāmapo objekti uz kolonnām; nespēj tikt galā ar internet-bāzētām «megadatu» aplikācijām. Dārgas licences, piegādātāju oligopols, nepieejams izejas kods.

Kā viens no atbildes gājieniem ir NoSQL (Not Only SQL): nav atšķirības starp datiem un dokumentiem; fleksibla datu shēma (bieži var iztikt bez iepriekš definēta datu modeļa); nereti Open source.

Informācijas lietošanas paradigmas mūsdienās

Cilvēki glabā dokumentus (arī video, audio u.tml., nu, objektus), nevis tabulas, rindas un kolonnas.

Dokumentu daudzums pieaug.

Cilvēki grib atrast tieši to, ko viņi meklē. Ja reanimatologs slimnīcā meklē informāciju par Galdiņu, viņam vajag maksimāli ātri iegūt datus par tikko ievesto pacientu Jāni Galdiņu, nevis galveno ārstu Pēteri Galdiņu vai saimniecības daļas pasūtījumus mēbelēm.

Cilvēki – kā jau mēs gūglē paši darām – svarīgāko informāciju grib redzēt rezultātu saraksta augšgalā.

Cilvēki grib atrast ĀTRI. Klik – un lai sekundes daļā ir rezultāts.

Cilvēkiem patīk zināt, cik rezultātu ir atrasts/atrodams. Skat, kā gūgle pasaka, cik ir atrasts – miljonu gadījumā „apmēram”, tūkstošu gadījumā precīzi.

Cilvēki grib paturēt iespēju atrast visu (minētā piemēra kontekstā – lai ir atrodama arī informācija par galveno ārstu uzgaidāmās telpas galdiņu pasūtījumu, tikai lai tā ir novietota tālākās lappusēs pēc pacientu datiem).

Cilvēki mēdz atkārtot vienus un tos pašus sekmīgos meklējumus atkal un atkal.

Galdiņš

Tagad iedomājamies SQL selektu informācijas pieprasījumam – atrodi man nesen ievestu pacientu, kuram uzvārds ir – vai varētu būt – Galdiņš. Atkarībā no DB struktūras, var sanākt tāds vidēji garš pieprasījums ar JOINiem. Šāda meklēšana kādam, protams, ir jāuzprogrammē – visticamāk ārstam jāizvēlas datu atlases forma, jāsameklē, kur ir lauciņš „Uzvārds” un tajā jāieraksta. Un jācer, ka uzņemšanā nav sajaukuši uzvārdu ar vārdu, kā tas varētu gadīties, piemēram, Paulam Konrādam.

Cilvēki ir meklējuši un atraduši dažādus risinājumus, un viens no tiem ir datus glabāt XML un šos XML indeksēt.

Piemērs ļoti vienkāršam XML, kur relāciju DB valodā būtu, piemēram, trīs tabulas –

  • Persona (Id, Vards, Uzvards),
  • Adrese (Pilseta, Iela, MajasNr, DzivoklaNr),
  • Saites tabula, kurā norāda adreses tipu – Mājas, Darba.

Pēc pārneses uz XML tas izskatītos, piemēram, šādi –dati par personu ir vienkopus, nevis izmētāti pa tabulām:
<Personas>
<Persona Id=1>
<Vards>Jānis</Vards>
<Uzvards>Bērziņš</Uzvards>
<Adrese Tips=“Mājas”>
<Pilseta>Rīga</Pilseta>
<Iela>Brīvības</Iela>
<MajasNr>235</MajasNr>
<DzivoklaNr>4</DzivoklaNr>
</Adrese>
</Persona>
<Persona>
……
</Persona>
</Personas>

Kāpēc XML? Tāpēc, ka teju bezgalīgi fleksibla struktūra un tāpēc, ka lasīšanas ātrums vienlaidus tekstam no diska objektīvi ir ātrāks nekā lasot datus pa trim izmētātām tabulām. Protams, katrs redzam mīnusus – update, delete, insert šādā struktūrā aizņem ilgāku laiku. Tāpēc joprojām pastāv dažādas DB un jāsaprot, kurā gadījumā kāda DB ir piemērotāka. Internetveikala gadījumā ātra un plaša meklēšana ir kritiski svarīga. Arī, piemēram, likumi.lv websaitam atlases ātrums un kvalitāte ir svarīga.

Clusterpoint

Analītiķu vakariņās ķidājām vienu no šādiem ļoti ātras (ar „ļoti ātras” saprotu milisekundes miljonu ierakstu gadījumā un sekundes simtdaļām miljardu gadījumā) meklēšanas (ne tikai, bet šeit sašaurināšu topiku uz meklēšanu) risinājumiem – Clusterpoint, tāpēc to aprakstīšu drusku sīkāk. Man patika – bet var būt tāpēc, ka pirmo reizi redzēju šādu sistēmu tik tuvu. To gan neatzinās pats lektors, bet pirms pāris nedēļām kādā pasākumā pie kafijas iepazinos ar vienu cilvēku, stādījās priekšā ka strādā www.likumi.lv. Uzslavēju par meklēšanas ātrumu likumi.lv, uz ko atbildēja – ā, tas tāpēc, ka mums ir Clusterpoint.

Klientam tiek uzdoti jautājumi, kāda veida informāciju viņš meklē visbiežāk, visvairāk? Es to domās nosaucu par search query driven development: pasaki, ko tu meklē, un es tev palīdzēšu izveidot tieši tādu rankošanas konfigurācijas failu, rulesetus – tos var vēlāk mainīt. Tādējādi tiek noteikts, ko parādīt saraksta augšgalā. Arī katrs objekts var sevi rankot uz augšu/uz leju. Piemēram, direktoram kā pirmie tiek atgriezti maksātspējīgākie klienti, kuriem šobrīd ir daudz naudas. Kādā brīdī, piemēram, datu ievades laikā konstatēts, ka šis klients, lai gan viņam šobrīd nav naudas, drīzumā kļūs pat ļoti maksātspējīgs. Šis klients tiek sarakstā uzrankots „uz augšu”. Dažādo iespēju saraksts ir tik liels, ka nemēģināšu pārstāstīt.

Jau minēju piemēru par slimnīcu, kurā ārstam svarīgākais Galdiņš ir pacients, saimniecības daļas vadītājam – neapstrādāts pasūtījums, savukārt grāmatvedim – neapstrādāts maksājums. Izejas dati visiem ir vieni un tie paši. Vai, piemēram, likumi.lv gadījumā lietotājs defaultajā rezultātā grib saņemt likumu, nevis sarakstu ar kaut kādu tā grozījumu uzskaitījumu – jaunākos, vecākos vai kā citādi nesaprotami sakārtotus. Lietotājs var sameklēt arī visus vajadzīgos grozījumus, protams, taču mērķis ir maksimāls ērtums konkrētajam klientam (skat. slimnīcas ārstu kā klientu) vai lielākajai kopai lietotāju (skat. likumi.lv weblapas apmeklētāju kā klientu).

NoSQL risinājums varētu būt labs jebkādas tekstuālas informācijas meklēšanai, piemēram, žurnalēšanas ierakstos. Vai meklēšanai visās kopš Gūtenberga laikiem iznākušajās avīzēs bibliotēkā.

Nav sudraba lode

Risinājums nav specializēts uz meklēšanu ne-teksta saturā, piemēram, video, tāpēc ar video ir tā, ka meklēšana notiek to aprakstošajos teksta datos. Ja vajag meklēt pašos attēlos vai video, tas arī būtu tehniski iespējams, tikai nav lietderīgi (sanāk video konvertēt uz tekstu, kodēt, dekodēt… – tam ir citas, labākas programmas).

Nav paredzēts sistēmām, kuru izdzīvošana ir atkarīga no insert, update, delete operācijām, jo tas XML struktūrā parasti aizņem ilgāku laiku. Taču var noderēt kā šādu sistēmu back-office meklēšanai. Daudzi klienti tā apzināti izvēloties, pie reizes iegūstot gan ātru meklēšanu, gan sistēmas datu back-up kopiju universālā XML formātā. Ja kas, Latvijā sadarbībā ar LU ir izstrādāts risinājums relāciju datubāzu satura pārlūkošanai; darbības princips – relāciju DB datus ielasīt kā XML un tad pa to var ērtā saskarnē pārlūkot kā vien vajag.

Ja ierakstu skaits ir tūkstošos, šāda sistēma neatmaksājas, jo ātrdarbība ar SQL ir apmēram līdzīga, nu, ja neskaita meklēšanas realizēšanas ērtumu. Miljonu, miljardu (terabaiti, petabaiti) ierakstu gadījumā – tad gan ir vērts apdomāt.

Sīkāka informācija un TRIAL versija šim konkrētajam http://www.clusterpoint.com/ Pārējos gūglējiet paši.

“Ultra-fast XML database server software with shared-nothing scale out architecture that uses ranking to index hybrid data for HUMAN-wise UNIFIED SEARCH across all your data”

27.02.2013 Analītiķu vakariņu „minūtītes” : Prototipēšana


27.februārī norisinājās kārtējās Analītiķu vakariņas par daudziem sistēmanalītiķiem aktuālu tēmu: lietotāja saskarnes prototipēšana.

Cik analītiķu, tik variantu: klātesošie no savas ikdienas minēja šādus rīkus un paņēmienus – Balsamiq, Mockup Builder, Axure XP, Justinmind Prototyper, SnagIt, Pencil, Adobe Fireworks, Microsoft Visio, Paint, WireframeSketcher, Powerpoint, Bootstrap un – zīmēt skices ar pildspalvu vai flomāsteriem uz papīra un nofotografēt :)

Šajās vakariņās guvām ieskatu:

  • Pencil – ātri apgūstams (nepilnu 10 minūšu laikā Miks Rozenbergs mūsu acu priekšā izveidoja autoveikala web lapas darbojošos un diezgan simpātisku prototipu) – ja man tagad tūlīt vajadzētu uzzīmēt dažu lapu saskarni, no visiem prezentētajiem rīkiem es izvēlētos šo.
  • Adobe Fireworks – ļoti jaudīgs rīks, rādīja lietotāja saskarnes profesionālis (Edgars Koroņevskis, SEB digitālā mārketinga vadītājs) – manuprāt, sistēmanalītiķiem, kuri paši nav web dizaineri, šis ir stipri par nopietnu – visas tās krāsu gradāciju iespējas un nianses…
  • Axure XP – funkcionāli bagātīgas iespējas, Valērijas Savinas stāstījums un rezultāts patīkami atraktīvs, Šo es, visticamāk, izmantotu, ja tagad veidotu jaunas, vidēji raibas vietnes prototipu. Patiesībā šis tiešām ir rīks, kuru brīvā laikā būtu labi pamācīties lietot.
  • Par prototipēšanu «pa taisno» HTML jeb Bootstrap stāstīja ar šo rīku reāli aizrāvušies programmētāji (viens no viņiem – Reinis Rozenbergs). Šis jau ir rīks, ar kuru prototipēt sistēmu, nevis zīmēt kādas lapas saskarni. Prototipā var likt iekšā reāli darbojošos funkcionalitāti, bagātīgs sagatavju klāsts, vajag HTML zināšanas. Šo es izvēlētos tad, ja meklētu, kur investēt savu naudu, un izdomātu investēt jaunā, atraktīvā autoveikala vietnē – noalgotu šos programmētājus.

Rīkotāju mājas lapā notiek balsošana, par kuru no šiem rīkiem izveidot atsevišķu darbnīcu. Pašlaik vadībā Axure XP.

P.S. Tēma pasaulē, protams, tiek cilāta un katrs sevi cienošs iesaistītais veido savus TOPus.

P.P.S. No savām sarunām esmu visvairāk dzirdējusi, ka lieto Balsamiq vai Axure RP

25.04.2012 Analītiķu vakariņu „minūtītes” – ERP sistēmas


Kā jau tas šajās vakariņās ierasts, sākumā brīdi pakašķējamies, vai biznesa analīze un sistēmanalīze ir vai nav viens un tas pats :-) :-)

Tātad, manas aizkadra piezīmes uz salvetes – no dalībnieku diskusijām, no pārdomām. Nepretendēju uz stenogrammu un neizplūdīšu detaļās par vakariņu pamattēmu – Eva Narunovska ir profesionāle, arī viņas CV iespaido. Eva uz jautājumiem par Uzņēmumu vadības sistēmām (ERP) atbildēs daudz labāk par mani.

Aktuālās tendences

Novērots pieprasījums:

  • lai katrs lietotājs var izveidot savu starta lapu – sākot ar fona krāsu, beidzot ar attēlojamās  informācijas secību;
  • lai sistēmā var redzēt, ko tieši šobrīd dara ar vajadzīgo lietu. Nevis – ka līgums „atrodas vīzēšanas procesā”, bet ka tieši šobrīd galvenais grāmatvedis to lasa. Šobrīd, šajā minūtē;
  • pēc analīzes, ko klients sistēmā klikšķina un kādā secībā, lai no tā ģenerētu piedāvājumus tieši šim klientam.

Ārzemju projektos pērk tavas zināšanas, tavu kompetenci, tavu padomu. Latvijas projektos noliek naudu un saka – uztaisi tā, kā es gribu.

Izraisās filozofiska diskusija

Viss par mums tiek pierakstīts. Kad zvanām, parādās bilde, informācija, vai esam labs vai slikts klients, vēsture, mūsu ienesīguma izvērtējumi, un nevajag brīnīties, kad atskan – toreiz, pirms 5 gadiem mēs ar jums… jo VISS tiek pierakstīts.

Arī, kad ejam prasīt algas pielikumu, kā uz delnas ir viss par mums – sākot ar vidējo atrašanās laiku darbā, beidzot ar programmas secinājumiem par mūsu nākotnes izredzēm.

Uz ko tas viss 10 gadu laikā aizies? Daļa izsaka prognozi, ka „mākoņu” lietas ies plašumā, datu apjomi augs, sistēmu pieraksti būs pierādījumi, valdība arvien vairāk kontrolēs visu. Būs tirgus niša – tava privātuma nodrošināšana. Ļoti dārgi maksās risinājumi, kuros datu apstrāde un glabāšana būs nodrošināta tā, ka valdība netiek klāt. Daļa izsaka cerību, ka aizies rights to be forgotten virzienā un mūsu mazmazbērniem nebūs jāskatās jestru vecvecmāmiņu jaunībsdienu bildes, tomēr, kā jau analītiķi, saprotam, ka arī dzēst var dažādi…

Tātad. Iešu pie klienta. Ar ko sākt?

Super! Viņš ir piekritis ar tevi vispār runāt! Novērtē to.

Noteikti pajautā: pastāsti, kā tu pavadi savu dienu? Pastāsti, kā tu redzi risinājumu?

Iegaumē viņa lietotos vārdus. Jā, arī – cedeles, špargalkas. Neskrien virsū ar saviem – modulāra, konfigurējama, mērogojama….

Neskrien ar savu “biznesa analīzes” un “procesu diagrammu” karogu. Sāc ar mazumiņu, kaut vai – rēķinu izdrukāšanu. Izturi pauzi! Sagaidi, kad klients pats paprasīs – klau, varbūt tev ir arī…? Protams, man ir :-)

Neliec klientam izvēlēties no gara saraksta, sevišķi, ja tās lietas ir līdzīgas. Noskaidro, ko viņam vajag, un sāc ar 3-4 piedāvāšanu.

Kad vāc informāciju, apstaigā visus. Esi gatavs, ka var nomainīties galvenais prasību uzturētājs. Piemēram, brīdī, kad sistēma – kura veidota pēc viņas ģīmja un līdzības – tiek ieviesta, galvenā grāmatvede dodas dekrēta atvaļinājumā.

Ja klients iepriekš ir strādājis ar citu sistēmu, būs  grūtāk, nekā ieviešot pirmoreiz. Rēķinies, ka gribēs „visu tāpat kā bija, tikai labāk”. Viltībiņa: izmanto iepriekšējās sistēmas nosaukumu. Jaunā būs uzlabota Mana Vecā Labā Sistēma, nu, MVLS 2.0.

Nelieto „pēdējais risinājums”, „pēdējās izmaiņas” u.tml. Jaunākais!

Sadarbība

Neceri uz brīnumu. Klients nav lasījis, nelasa un nekad arī nelasīs tavus procesu aprakstus, prasību specifikācijas un projektējumus un citus murgus. Viņš tos parakstīs, kad tu piespiedīsi. Nedomā, ka sarežģījumi atrisināsies brīdī, kad pavicināsi viņam papīru – re, skat, tu pats parakstīji, ka gribi šādi. Klients jutīsies apčakarēts, lai tur būtu kaut 10 viņa paraksti.

-un kā jūs cīnāties ar klienta prasību nepārtraukto maiņu? –mēs necīnāmies. Mēs sadarbojamies!

Kad klients zvana – nekas neiet, viss ir uzkāries un sistēma nekam neder – ieklausies rūpīgi. Visticamāk, tas ir zvans – klau, lūdzu, atnāc un nomierini manus darbiniekus (nu, viņus, manus vecos labos – raudošo grāmatvedi, satrakojušos ekonomistu, histērisko sekretāri).

Strādā, lai klients kļūst par tavu vēstnesi. Kaut vai – lai atnāk uz semināru un pastāsta par jūsu sadarbības pieredzi. Efektīvs paņēmiens! Arī analītiķu vakariņās tiek izmantots.

Kad esi uzlicis sistēmu klientam testēt un nav ziņu – nedēļa, divas… – esi drošs: viņš uz tavu sistēmu nav pat paskatījies. Par to, ka klients ir sācis to lietot, tu zināsi. Jo saņemsi uzreiz ap 100 pieteikumiem

IT, kā zināms, varam visu, tikai dodiet laiku un naudu. Vai ir labi klientam teikt “tas nav iespējams”? Formāli godīgi būtu teikt – jā, tas ir iespējams, bet/un/taču… No analītiķu pieredzes: klientam paliek atmiņā tikai pirmā daļa – ka ir iespējams. Tāpēc ieteikums runāt apmēram šādi: …konkrēti jūsu šībrīža situācijā tas nav iespējams (nav vēlams). Tas parādīs gan ka iedziļinājāmies, gan ka nav iespējams, gan ka būtu – citā situācijā.

Palīdzi klientam arī pēc tam izvērtēt, vai to prasību bija vērts ieviest?

Nav smuki no viena klienta iekasēt maksu par lietām, kuras tu pārdosi tālāk arī citiem. Paņēmieni ir dažādi – sākot no kļūšanas par partneri, beidzot ar izmaiņu izmaksu sadalīšanu uz vairākiem klientiem.

Ja kāds piedāvā tavam klientam lētāku cenu, neskrien gudri skaidrot, kāpēc tavējā ir 15x lielāka. Uzvedini klientu uz jautājumiem. Hmm, kā viņi domā nodrošināt serverus? Kā viņi pārnesīs vecos datus? Ļoti iespējams, ka tas beigsies ar tava klienta pateicību par paglābšanu no sasteigta lēmuma.

Nenonāc opozīcijā ar klientu. Pat ja es uzvarēšu, es zaudēšu.

Klientam ne vienmēr ir taisnība. Taču klientam vienmēr ir nauda.

Atbildi par to, ko pieradini

Diskutējam, kas notiek brīdī, kad programma faktiski priekšā pasaka/izdara visu?

1)      Kādu brīdi cilvēki tai netic. Pārrēķina ekselī, uz lapiņas, uz kalkulatora. Priecājas – re, programma sarēķināja tāpat kā ES! Kāda gudra!

2)      Algoritmi sarežģījas, arī ticība programmai rodas un kādā brīdī cilvēks saprot, ka viņš uz sava kalkulatora vairs nemaz nevar izrēķināt šo rezultātu. Zūd sajūta – ES VARU. Rodas – esmu programmas piedēklis, datorpeles pagarinājums.

3)      Darbiniekiem, kuri ir motivēti pašattīstīties, zūd savas kompetences sajūta, kā rezultātā var uznākt arī kārdinājums mainīt darbu.

4)      No bezdarbības lietotāji sāk piesieties lietām programmā, kuras citādi pat neievērotu.

Labs vadītājs:

1)      Sapratīs, vai viņa situācijā darbinieki ir bandinieki vai Cilvēki, jo rīcība atšķirsies. Vienā gadījumā – pieņem vai tinies, otrā – darbs ar cilvēkiem, motivēšana.

2)      Iespējams, kopā ar programmas ieviesējiem strādās, lai darbiniekiem būtu sajūta – re, it kā tik sarežģīta sistēma un es to saprotu! Es varu!

3)      Kompetences zuduma sajūtas risku apzināsies un pārvaldīs. Piemēram – darba vidū viktorīnas par profesionālajiem jautājumiem.

4)      Prognozēs (vai vismaz pamanīs) darbinieku laika atbrīvošanos un novirzīs to lietderīgi.

Stāsts iz dzīves

Jānis gāja pirkt kādu vajadzīgu lietu. Dārgu – 800 ls. Naudas maz, tā un šitā, un viņam „izņēmuma kārtā” un „kā īpaši labam klientam” piešķīra 10% atlaidi. Jānis laimīgs, tomēr 80 lati ietaupīti. Nākamajā dienā Jānis saņem SMS no šī veikala – akcija, visām precēm 20% atlaide.

Pagājuši jau kādi 7 gadi, taču šo apčakarējienu Jānis neaizmirst. Starp citu, man līdzīgi pirms pāris dienām bija ar kurpēm. Veikalā -10% un nākamajā dienā visiem klientiem SMS „uzrādi un dabūsi -20%”. Ergh.

Morāle: domā, ko sūti klientam.

P.S. Arī iz kāda analītiķa dzīves. Neviens nestāsta, kad tu pajautā – klau, konkurenti, kā jūs darāt to? Toties – ja izliksies par potenciālu klientu (vai varbūt pat kļūsi par klientu), izstāstīs ne tikai to vien.

Analītiķu vakariņas un CBAP sertificēšana


Kas cits sistēmanalītiķim asti un profesijas prestižu cels, ja ne pats?

Tagad arī Latvijā ir tāda iespēja. Biedrība http://latvia.theiiba.org, tviterī http://twitter.com/iiba_latvia. Lai iestātos, jābūt lielās IIBA asociācijas biedram. IIBA – Starptautiskais biznesa analīzes institūts. Katra mēneša pēdējā trešdienā ir “Analītiķu vakariņas” (kolosāls nosaukums :-) ).

Īsumā par 30.03 „Analītiķu vakariņu” iespaidiem

Ameklēju pirmoreiz (un nožēloju, ka palaidu garām iepriekšējās – jo bija tik jauki). Tēma bija – analītiķu sertifikācija un jaunpienācējiem stāsts par to, kas ir IIBA Latvijas nodaļa. Kas attiecas uz terminoloģiju „biznesa analītiķis” vs „sistēmanalītiķis”, vakar izskanēja, ka biznesa analīze ir daļa no sistēmanalīzes, lai gan precīzas definīcijas neesot un par to jau agrāk esot risinājušies kaismīgi strīdi.  Manā subjektīvajā skatījumā biznesa analīze un sistēmanalīze būtībā ir dažādas lietas. Biznesa analītiķis skatās, kā pārvaldīt, teiksim, klientu pieņemšanas procesu (un var pat nezināt, ka tur kaut kur ir programma), savukārt sistēmanalītiķis parasti saņem jau puslīdz gatavu procesu, kuru saprot (intervē, lasa, pēta, skatās…), tad formalizē un novada līdz strādājošai programmai tā procesa atbalstam (žargonā to sauc par bardaka automatizāciju). Ļoti labs sistēmanalītiķis sevī apvieno abas šīs lietas: vispirms sakārto (optimizē, konsolidē, novērš pretrunas…) biznesa procesus un tad liek tos programmā. Bet… te iederas šī bildīte.

Sertifikācija

Nosacīti 1.līmenis: CCBA: Certification of Competency in Business Analysis – demonstrēt, ka analītiķa spējas atbilst noteiktam pamatprasību kopumam. Tēlaini varētu pielīdzināt prašanai braukt ar vieglo auto.

Nosacīti 2.līmenis (augstāks) CBAP: Certified Business Analysis Professional— vecākajiem analītiķiem kā pierādījums, ka spēj pacelt dažādas sarežģītības projektus. Skaitās augstākā sertifikācijas pakāpe, ko var iegūt profesionālis informācijas sistēmu un biznesa sistēmu analīzes jomā. Tēlaini varētu pielīdzināt spējai ar auto palīdzību izbraukt astotnieku, veikt sarežģītu loģistiku un vispār pārvaldīt autoparku.

Sertifikācijai ir pamatīgas priekšprasības, noteikts prakses stundu skaits (atšķirīgs CCBA un CBAP), noteikts profesionālās pilnveidošanās stundu skaits un divas rekomendācijas. Tāpēc formalitātes jāsāk kārtot ļoti savlaicīgi, vismaz pāris mēnešus iepriekš jāsāk vākt informācija. Priekš CBAP:

• Sufficient Work Experience – 7,500 hours (i.e., five (5) years) of BA work experience in the last ten (10) years engaged in tasks specifically aligned with the BABOK®.

• Expertise in the BABOK® Guide Knowledge Areas – Demonstrated experience and expertise (i.e., a minimum of 900 hours (i.e., 6 months) in at least 4 of the 6 BABOK® knowledge areas.

• Minimum Education – You must meet the minimum education requirement of high school or equivalent.

• Adequate Professional Development Hours – 21 hours of BA-related professional development within the last 4 years.

• Evidence of Certification Suitability – Two references to indicate that you are a suitable candidate for the CBAP® certification, whether a career manager, an internal or external client or a CBAP® recipient.

Eksāmens

150 jautājumi ar atbilžu izvēlēm, ilgums 3.5h. Sākot ar marta vidu, šos sertifikācijas eksāmenus Latvijā piedāvā kārtot Baltijas Datoru akadēmija (BDA). Pagaidām BDA nepiedāvā sagatavošanās kursus un apmācību biznesa analītiķiem – tādas iespējas jāmeklē citur, piemēram, http://www.thebamentor.com.

Eksāmenā nav atļauts izmantot nekādus palīgmateriālus (arī EN-LV vārdnīcu ne). Var izvēlēties, kārtot uz datora (rezultātu ok/neok pasaka uzreiz pēc eksāmena) vai uz papīra (tad rezultāts mēneša laikā).

Būtībā tā ir zināšanu pārbaude pret BABOK (Business Analysis Body of Knowledge). Jāpiebilst, ka šī grāmata nav metodoloģija. Tā drīzāk ir enciklopēdija par to, kas biznesa analītiķim ir jāzina un no kā sastāv pats analīzes process, atslēgvārdi un jēdzieni, kas ir requirement, kas ir rule, kas ir enterprise architecture, kas ir business architecture, pārklājuma matrica utt. T.i. ja analītiķim-praktiķim nesagādātu lielas grūtības argumentēt (lasiet: dažreiz arī demagoģēt), ka pareizas ir visas vai vairākas atbildes, jāatceras, ka šajā sertifikācijā pareizā atbilde būs tas, ko par to saka BABOK. Un ļoti rūpīgi jālasa jautājuma formulējums: ja tur ir jautāts „which is best for understanding”, tad tas nenozīmē, piemēram, „which is best for solving”.

Manas domas

Iestāšanās IIBA: viennozīmīgi PAR ($65 gadā). 30.03 sistēmanalītiķu vidējā koncentrācija uz kvadrātmetru bija iespaidīga. Sajūta – kā jau starp savējiem. Īpaša atzinība RTU mācībspēkiem – bija klāt un izteica gatavību operatīvi pielāgot un papildināt savas mācību programmas arī ar zināšanu sniegšanu šādas sertifikācijas vajadzībām. Tā kā es esmu LU patriote, strādāšu, lai aktīvāk savestu kopā LU Datorikas fakultāti ar IIBA Latvijas biedrību. Galu galā Matemātikas un informātikas institūtā (MII) top mūsu pašu zinātnieku izstrādāts izcili labs rīks (esmu to redzējusi darbībā projektos un doktorantūras ietvaros lietoju arī pati), platforma – kurš zina GRADE, lūk, šis rīks ir tāds kā super-turbo GRADE ar iespēju veidot gan savas domēnspecifiskas valodas, gan veikt modeļu transformācijas, gan ērti zīmēt labas diagrammas, un analītiķi būtu īstā mērķauditorija – gan darīt zināmas praktiķu vēlmes zinātniekiem, kamēr siltas, gan apdomāt iespēju šo rīku izmantot sava darba atvieglošanai.

CBAP sertifikācija (izmaksas ap $450-$1200 (tas ja ņem kādus kursus): būtu interesanti. Dzirdēju baumu, ka LV tenderos jau esot parādījušās prasības, lai būtu šie sertifikāti (te gan jāpatur prātā, ka var būt kāmīša skrējiena efekts – tie, kuri sertificēsies, var pielikt pūles, lai šādu prasību arvien biežāk iekļautu, tādējādi liekot pārējiem neatpalikt, jūs jau atceraties slaveno atziņu – ir ātri jāskrien, lai noturētos uz vietas). Kā minēja viena no dalībniecēm, startējot uz ārzemēm tādu kompetences pierādījumu – CBAP – esamība esot pašsaprotama lieta.

Latvijā šobrīd ir divas CBAP sertificētas sistēmanalītiķes, drīzumā noteikti būs vēl – un tas vedina domāt, ka principā tas IR izdarāms, gan priekšnosacījumi izpildāmi, gan eksāmens nokārtojams. Par sevi vēl domāšu, jo gribēšana kā tāda ir, taču ar brīvo laiku tā ir kā ir. 

CBAP sertifikācijas jautājumu piemēri (atbildes ir šajos slaidos) un vēl 150 piemēri

What technique might be used to help familiarize the project team with the existing solution scope?

A. Context scope diagram

B. Requirements workshop

C. Structured walkthrough

D. Brainstorming

Non-functional requirements are best described as what?

A. Deliverables that are progressively elaborated on

B. Nothing. If they do not function they must be design elements

C. External interfaces the product must have

D. Internal interfaces the product must have

Which of the following roles have the most effect on the business analysis approach selected?

A. Business analyst, implementation SME (subject matter expert), project manager

B. Tester, regulator, and sponsor

C. Project manager, sponsor, supplier

D. Business analyst, tester, regulator

P.S. Katrā ziņā savā plānotājā jau ierakstīju nākamās Analītiķu vakariņas. Jāpiesakās savlaicīgi, vietu skaits ierobežots, ir arī neliela dalības maksa.

%d bloggers like this: