Archive for the ‘Analītiķu vakariņas’ Category

Kas ir biznesa analītiķis un kam tas vajadzīgs? Bet sistēmanalītiķis?


Nesen atkal pārrunājām analītiķu asociācijā, ka nereti uzņēmēji, pasniedzēji, studenti īsti neizprot biznesa analīzes, arī sistēmanalīzes, pienesumu. Stereotips, ka vajadzīga tikai programmēšana, ir dzīvelīgs.

Grūti atbildēt pat gari, kur nu vēl īsi. Asociācijā mēģinām pēc iespējas īsāk un plašai auditorijai saprotamāk noformulēt, kas tas ir. Smagi iet… mēģinām ij ar santehniķu, ij ģimenes ārstu piemēriem…

Man tuvāka ir sistēmanalīze, esmu noformulējusi tādu kā reklāmsaukli: „ar mani komandā jūsu sistēma darīs to, ko jūs gribat, lai tā dara”. Varbūt biznesa analītiķim varētu šo adaptēt kā “ar mani komandā jūsu uzņēmums sasniegs to, ko jūs gribat, lai tas sasniedz”?

Biznesa analīze kā darbs neienāk prātā, nav motivācijas tai, BA pienākumi viltīgi ieslēpjas citos. Kas tad tur liels, vajag ieviest pašapkalpošanās portālu un e-rēķinus? Pasauksim programmētāju, uztaisīs. Jā, var paveikties un ir programmētāji, kam analīzes darbi ir asinīs kā tik pašsaprotami, ka ļauj ar lielu pārliecību sludināt– ne tāda analīze, ne analītiķi nav vajadzīgi, heh, piemirstot, ka tādi darbi patiesībā jau tiek darīti. Es jau nesaku, ka noteikti vajag atsevišķu lomu. Taču biznesa analīze pelnījusi būt saulītē, ne sētmalē.

Darba sludinājumos BA darbi mēdz slēpties zem citiem nosaukumiem – enterprise architect, consultant, solutions coordinator… Un otrādi, zem BA birkas samet visus darbus, kuri palikuši pāri. Lūk, piemērs diviem sludinājumiem ar tādu pašu amata nosaukumu:

BAslud

Mans divcentu mēģinājums tantei Bauskā skaidrot, ar ko tie analītiķi atšķiras

Pieņemsim, ģimenes ārsta prakse laukos. Nodzeltējušas pacientu kartiņas plauktā pēc dzimšanas gadiem. Pa kreisi uz galda reģistrēšanas žurnāls, pa labi uz lapiņas sarakstīti tie, kuriem par potēšanu jāpiezvana.

Valdība paskatās – atkal tie igauņi mums priekšā. Steidzami vajag kaut ko izdomāt. Vajag datorizēties. Tā nu atnāk analītiķis, kuram jāuztaisa sistēma „Lauku ārsts v0.0.1.0.3.9.”

Ārste saka – man nav laika, re, kur mans palīgs, parunājieties.

Palīgs ir pavisam parasts, normāls cilvēks, zinoša mediķe, kundze pensijas gados, datora pieredzes nav.

Parasts biznesa analītiķis

Parasts analītiķis uzklausīs ārstes palīdzi un tā, kā viņa dara, arī sazīmēs modeli un sistēmas ideju. Kad jauns pacients, viņa sameklē plauktā starp veidlapām tukšu grāmatiņu, paskatās žurnālā, kāds pēdējais lietotais numurs, ieraksta uzvārdu, dzimšanas gadu, personas kodu…

Reizi mēnesī caurskata šajā mēnesī dzimušo kartiņas, lai atrastu, kuriem nav atzīmes par potēšanu. Izveido sarakstu un liek ķeksīšus pretī sazvanītajiem.

Analītiķis tā arī uzzīmē procesu, kā tas programmā notiks:

  • Pacientu kartiņu ievade sākas ar to, ka no mapītes izvēlas sagatavi, tajā ievada brīvi izvēlētu numuru, ieraksta uzvārdu, pēc tam personas kodu, dzimšanas gadu…
  • Potējamie: atlasām dzimušos periodā dd.mm.gggg – dd.mm.gggg un lapiņā „Potes” teksta laukā var redzēt, kādas ir, nav…

Labs biznesa analītiķis

Savukārt labs biznesa analītiķis uzklausīs, apdomās, sapratīs mērķi, sapratīs procesu, izdomās, kā vēl šo mērķi var sasniegt, spēs saprast, kādi datu vienumi ir nepieciešami, orientēsies tehnoloģiju iespējās, pamanīs procesa uzlabojumu variantus, papētīs, kā tas notiek citur. Arī datu līmenī sapratīs saites, validāciju iespējas, automatizācijas iespējas.

Pēc tam, kad izdomāts process, viņš/-a uzdizainēs sistēmu, lai tā atbalsta šo procesu.

Informācija par tiem, kuri maina ārstu, atnāks automātiski, visu veidu identifikatori ģenerēsies, potējamajiem automātiski tiks nosūtīts atgādinājuma epasts, pirms jauna pacienta reģistrācijas notiks pārbaude, vai tāds personas kods ir Iedzīvotāju reģistrā, vai nav paralēli reģistrēts citur… Ja zvana telefons ar atpazītu pacienta numuru, uz ekrāna parādīsies iespēja atvērt šī pacienta kartiņu, pierakstīties uz konsultāciju varēs arī prakses mājaslapā u.t.t.

Visticamāk, ka ārsta palīdze vispirms būs neapmierināta, tā kā tas maina ierasto, bet pēc lietošanas iepatiksies – tā vajadzētu būt, jo mums taču strādāja labais biznesa analītiķis :)

Sistēmanalītiķis

Savukārt sistēmanalītiķis jau zināmas prasības novedīs līdz lietošanai. Minētajā gadījumā visticamāk, ka viņš būs tas, kurš zīmēs konkrētās ekrānformas, pārskatus, uzprojektēs datu apmaiņu starp sistēmām, kā arī dos uzdevumus programmētājiem, testēs.

Cita piemēra gadījumā – pieņmsim (tfu tfu tfu), valdība nosaka jaunu PVN likmi un ievieš jaunu nodokli par valsts gaisa lietošanu. Sistēmanalītiķis nedomās, kāda ir patiesā vajadzība šādam nodoklim un vai var budžetu pildīt kā citādi.

Parasts sistēmanalītiķis

Pavisam parasts sistēmanalītiķis uztaisīs pie katra nodokļa lauciņu, kurā ierakstīt likmi, un pieliks ķeksīti, kur pie nodokļa ielikt lauciņā „par elpošanu”. Pēc tam katrā pārskatā, katrā apstrādē pieliks, ka gadījumā, ja šim nodoklim ķeksītis ir aizpildīts, tad…

Labs sistēmanalītiķis

Labs sistēmanalītiķis izdarīs tā, ka likmju klasifikatorā būs jauns ieraksts, kur PVNam automātiski no klasifikatora pēc perioda nolasīsies aktuālā likme. Tiks pievienots jauns ieraksts nodokļu grupu klasifikatorā un nodokļu klasifikatorā vajadzīgajiem tiks pievienota saite uz jauno gaisa nodokļu grupu.

Šeit iederētos Gojko Adzic citāts: Ja maza izmaiņa biznesā izraisa lielas izmaiņas programmatūrā, tad tā ir slikta sistēmas arhitektūra. Un arhitektūra atkal ir cits stāsts.

Kāda izcila biznesa analītiķa dzīves gājuma piemērs

Šeit vietā būs pieminēt nesen konferencē sastapto Isha Jain, UK IT Business Analyst of the Year ’2013 – izcila analītiķe, fascinējoša sieviete (starp citu, viņas māte esot latviete – Isha mani uzmeklēja, lai parunātos par Latviju).

Tēma bija A Business Analyst Journey to a Lead Business Analyst. Jau pats prezentācijas sākums bija iespaidīgs – ierodas vienkārša meitene kostīmiņā, it kā viena no mums, taču tā stāja, cieņpilns un vienlaikus pašpārliecināts smaids, un sāk ar to, ka – You are my stakeholders right now and I want to be sure that you step out of this room after achieving your objectives. Uzklausīja, ko vēlamies dzirdēt, pierakstīja uz tāfeles, un sekoja līdzi, lai tas tiek ne tikai pastāstīts, bet arī uzdevēji (atcerējās katra seju un vārdu) apstiprinātu, ka atbilde ir saņemta.

Isha sākusi kā analītiķe – ar jautājumiem. Vispirms sev:

  • What is the scope? Is it replacing system for 200 people across the department or is it more?
  • What will business tell me as their requirements? Do I want to hear it?
    • System Problems?
    • Things they do in spreadsheets? (~100)?
  • Will that give real Value to the programme?
  • Can I be sure that the requirements will be the real business needs?
  • Can I be confident that these requirements will eliminate all inefficiencies in the department and deliver real business benefits?
  • Remember – people’s perception is built from how you position yourself

Likumsakarīgi Isha tika ātri vien pamanīta un paaugstināta. Nu jau viņa ķērās klāt BA lomas definēšanai:

I want a BA to:

  • Find real requirements that give real value
  • Document Requirements
  • Write Business case
  • Write an Investment proposal
  • Create business process models
  • Be bridge between business and IT
  • Help developers to clarify requirements

I got authority -> people started to believe me -> people started to follow me

Kad Isha pārņēma BA virziena vadību, National Grid uzņēmumā bija 7 virzieni (gāze, elektrība u.tml.), katrā „neaizstājami” analītiķi. Viņa saprata, ka tas nav veselīgs modelis, izveidoja analītiķu “pakalpojumus”, un ieviesa analītiķu rotāciju – BA’s as a single entity (a pool).

Šobrīd Isha ir BA senior management:

  • Established framework – tools for req. management, templates, different workshop styles (200 people there)
  • Created BA service catalogue to avoid people body shopping – provide services, not bodies!
  • Recommends the best approach
  • Leading IS and senior leaders through change
  • Identifying best practices in the industry
  • Provide services not just to project but to wider business
  • Bringing visibility to BA Practice, mentoring BAs
  • Maintains performance hubs – measure, improve
  • Building Skills framework/Training catalogue

Ko viņa iesaka un pati ar savu piemēru konferencē rādīja:

  • Think. Ask. Repeat as necessary :)
  • Remember and answer questions. All questions. Always.
  • Proud and happy doing my job
  • Take time out to celebrate Success and Achievements

Lūk. Tieši tik vienkārši :) :)

Advertisements

Mani pirmie iespaidi par BABOK v3


Kā jau varbūt dzirdēts, BABOK jeb biznesa analīzes vadlīnijām – A Guide to the Business Analysis Body of Knowledge® top trešā versija. Publiskais review beigsies 11.jūlijā.

Uzrakstīju savus pirmos iespaidus. Iedvesmojos no 26.jūnijā Analītiķu vakariņām par šo tēmu un Gundegas Lazdānes stāstītā. Šī nav recenzija! :-)

Liriska atkāpe – PMI ir startējis savu Professional in Business Analysis (PBA) sertifikāciju, spēcīgu konkurentu IIBA Certified Business Analysis Professional (CBAP). Vienā teikumā –

  • PMI PBA skatījumā biznesa analītiķis atbalsta projekta vadītāju, uzsvars ir uz BA lomu tieši projekta izstrādes laikā un sedz hibrīdgadījumus, kad BA un PM saplūst,
  • IIBA jeb CBAP gadījumā – BA atbalsta organizāciju, projekts ir tikai daļiņa no biznesa analīzes, skatās stratēģiskāk, plašāk, un piemērotāks klasiskiem BA.

No vienas puses man kā tipiskam hibrīdam ir žēl, ka agrāk nebija PMI PBA, bet no otras puses – pašlaik uzskatu, ka PMP + CBAP ir jaudīgāks zināšanu komplekts par vienu pašu PMI PBA.

Labi, atgriežamies pie CBAP un BABOK. Tas ir kļuvis stipri savādāks un iesaku mācības beigušajiem iespringt un nokārtot CBAP pēc v2. Eksāmeni pēc jaunā sāksies ~2015. gada pirmajā pusē.

Tātad:

  1. Mainīta Biznesa Analīzes definīcija (manuprāt, legalizēts fakts, ka biznesa analītiķis dara daudz vairāk nekā „tikai” pilda uzdevumus un paņēmienus, lai izzinātu prasības un apkopotu tās dokumentos):

BAdef

  1. Mainīta Prasības definīcija (manuprāt, uzliekot lielāku atbildību analītiķim, jo pirms tam izrietēja, ka izteicējam būtu jāspēj noformulēt, kādu problēmu tā risinās vai kādu mērķi sasniegs. Tagad prasība var būt praktiski jebkas)

ReqTab

  1. Ieviests dizaina jēdziens un definīcija, un Prasību analīze un komunikācija turpmāk būs Requirements and Design analysis, kā arī BA uzlikts par pienākumu par to domāt. Bet! Ar to nevajag saprast tehnisko projektējumu – bet to, ka līdz šim teorētiķi centās – why vs how u.c. veidi – novilkt līniju, kad beidzas prasības un sākas projektēšana. Tagad šī līnija ir izpludināta. IT projektos tas ir uzskatāmāk, bet vairāk grūtību bija cita veida projektos, piemēram, klasiskajā biznesa analīzē prasību analīzes rezultāts arī pirms tam praksē nebija „esmu secinājis, ka vajag uzzīmēt procesu X” – tāpat jau rezultātā bija uzzīmēts tas process X.

Dizaina detalizācija nav noteikta, bet ir maigi definēts vispārīgums – …might… at some level….

“Designs are usable representations that focus on both the solution and an understanding how value might be realized by a solution if it is built.”

“…business analysts are also responsible for the definition of design, at some level, in a change initiative.”

IT gadījumam ir piebilde, ka

“They define requirements to a level of technical detail that will be used as part of solution design and input into technical design.”

P.S. Tā kā par šīm robežām šķēpi tiek un tiks lauzti, pielieku ilustrācijai bildi ar piemēriem no BABOK v3 sākumversijas, cik trausla un nedefinējama ir robeža:

Req

Starp citu, pie BA vēlamajām īpašībām pievienotas:

  • Conceptual Thinking
  • Visual Thinking
  1. Veikts biznesa analīzes izpratnes un veikšanas standartizācijas mēģinājums – Business Analysis Core Concept Model (BACCM), a model of six terms that have a common meaning to all business analysts and helps them discuss business analysis using a common terminology. Katras nodaļas sākumā ir tabula ar šīs nodaļas saturu caur šo pamatkonceptu prizmu. Kā iepriekš lasījāt, tie parādās arī pašā biznesa analīzes definīcijā.

BACCM

  1. Līdz šim BABOK-am pārmests, ka tas vairāk asociējās ar IT risinājumiem. Lai BABOK un biznesa analīzi padarītu vispārīgāku, pievilcīgāku, lasāmāku plašākai auditorijai – mārketingam, korporāciju stratēģiskajām analīzēm, dažādiem IT u.t.t., ieviestas t.s. perspektīvas, kurām biznesa analītiķi pievieno vērtību, un aprakstīts, kā lasīt BABOK nodaļu saturu caur šo perspektīvu prizmu.

Piemēram, ja Tu esi IT BA, tad Tavā gadījumā:

  • Strategy Analysis – lasi ar domu, ka Tev tas palīdzēs izanalizēt, kā organizācijas izmaiņas ietekmēs IT sistēmas, kā tās tiek pašlaik izmantotas, kā sadarbojas un kā būt nākotnē,
  • Requirements Analysis and Design Definition – izvirzīt prasības risinājumam un veikt ne-tehnisku projektēšanu jeb dizainu: piemēram, raksturot, kādus biznesa datus šī sistēma apstrādā,
  • Solution Evaluation – novērtēt, vai izmaiņas IT sistēmā saderēs ar uzņēmuma procesiem.

Perspektiva

  1. Iepriekšējā versijā smagnējā un ne visai intuitīvi saprotamā Enterprise analysis nodaļa (mēdzām to voluntāri interpretēt kā projekta uzsākšanas priekšdarbus), kā rezultāts bija neiztulkojamais Business Case, tagad nomainīta uz Strategy (dažās v3 iterāciju redakcijās pat bija Situation) Analysis un beidzot ir skaidrs, ka attiecināma uz praktiski jebkādu analīzi:

„…can be conducted on the enterprise on the whole, or at any level or on any component of the enterprise. Every change, no matter how large or small, must be driven by a strategy…”

kā arī rezultātu loks paplašināts – var būt plāns, arhitektūra, vīzija, TO-BE procesu modelis u.c.)

  1. Cauri vijas palielināta savstarpējas cilvēku sadarbības (collaboration) nozīme. Pirms tam bija uzsvars vairāk uz izzināšanu, iztaujāšanu un rezultātu apkopošanu, tagad ir uz sadarbību. Tas parādās arī niansēs, piemēram, no komunikāciju prasmēm izņemts Teaching, bet pievienots Non-Verbal Communication un Listening. Pie sadarbības prasmēm pievienots Teaching unNegotiation and Conflict Resolution. Lai attīstītu sadarbību, ieviesti jauni paņēmieni – Personas, Collaborative Games.
  1. Kopumā pievērsta ievērojami lielāka uzmanība izmaiņu pārvaldībai un glosārijā ieviesta definīcija: “A controlled transformation of the enterprise.”
  2. Papildināts un pārskatīts paņēmienu jeb tehniku saraksts – izmaiņu ir daudz. Bija 34, tagad ir 46. Jaunās vai mainītās:
    • Backlog Management
    • Balance Score Card
    • Business Capability Analysis
    • Business Model Canvas
    • Collaborative Games
    • Glossary (izdalīts ārā no Data Dictionary)
    • Decision Modeling
    • Item Tracking
    • Problem Tracking
    • Reviews
    • Risk Analysis and Management
    • Roles and Permissions Matrix
    • Scenarios (izdalīts ārā no Use Cases)
    • Stakeholder List, Map, or Personas
    • Workshops (bija Requirements Workshops)

Tagad BABOK kā lasāmgabals ir kļuvis lasāmāks, jo pirms tam jau tepat blogā kreņķējos, ka BABOK nepieradušam lasītājam patiešām var šķist visai garlaicīgs.

Bet vai un kā tas līdzēs personīgajā izaugsmē un eksāmenā – ceru, ka par to pastāstīs tie, kuri mācīsies un kārtos pēc jaunā. Lai izdodas! :-)

23.05.2014 Analītiķu brokastu “minūtītes” : OMG OCEB 2 sertifikācija


2014. gada  23. maijā piedalījos BDA rīkotajās Biznesa analītiķu brokastīs. Kā jau zināms, bezmaksas brokastu nav un patiesībā šis bija labi noorganizēts veids, kā savākt analītiķus un pastāstīt viņiem, ka sākot ar šīgada rudeni BDA būs pieejamas apmācības un sertifikācija OMG OCEB 2 Fundamentals jeb Object Management Group Certified Expert in BPM 2™ pēc BPMN 2 notācijas. Semināru vadīja Gundega Lazdāne, BDA pasniedzēja un FMS Biznesa analīzes grupa vadītāja.

Sertifikācijai kopā ir trīs līmeņi – Fundamentals (par to ir šis stāsts), Intermediate (ar laiku arī šo varēšot BDA apgūt), Advanced. Pirmā grupa mācīsies ~24. – 26. septembrī, izmaksas varētu būt kā par 3 dienu BDA kursiem + eksāmens (nu, piemetu uz aci pēc www.bda.lv izcenojumiem, ka ~600-800 EUR).

Mērķauditorija: analītiķi – gan biznesa, gan sistēmanalītiķi.

Gala ieguvums, kādu es saskatīju – prasme un motivācija zīmēt BPMN diagrammas un, iespējams, ar laiku gan PPA papīru kalnus daļēji aizstāt ar tām, gan pašam sastrukturēt pieeju, gan savā starpā komunikācijā izmantot. Kolēģi no liela IT uzņēmuma seminārā teica, ka sākumā lietojuši kā skices paši savai saprašanai, sākuši rādīt klientam, ātri vien klienti paši sākuši pieprasīt, un tagad arī testētājiem un programmētājiem darba uzdevumi tiekot pārvaldīti caur BPMN: procesi, sadarbība, saruna, horeogrāfija (process, collaboration, conversations, choreography), jeb vienkāršāk izsakoties – vizuāli diagrammā apraksta, kādas aktivitātes kādā secībā un pie kādiem nosacījumiem notiek, kā savstarpēji mijiedarbojas un kā tiek koordinēta sadarbība.

Starp citu, pilnīgi legāla atbilde uz jautājumu – kam tāds BPMN vispār vajadzīgs? – ir arī šī: tas palīdz man kā analītiķim saprast un aprakstīt procesus.

OMG šoreiz nav Oh My God! :-), bet gan jau būs, kad sākšu pa īstam mācīties.

Rīki, ar ko dalībnieki darbā zīmē, tika minēti gan bezmaksas, gan maksas: QPR,  SPARX Enterprise Architect, Bonita, MS Visio.

Par eksāmenu (raksta beigās ir ar Gundegas laipnu atļauju pielikti daži iespējamu jautājumu piemēri)

Šim eksāmenam (atšķirībā no CBAP u.tml) nav priekšnosacījumu – nevajag apmācību punktus, pieredzi u.tml. Samaksā un kārto. Pagaidām nav zināms, vai būs nepieciešama resertifikācija, bet paskatījos, ka dažiem citiem līdzīgiem ir ik pa 3 gadiem.

Tests, 90 jautājumi. Lai nokārtotu, jāatbild uz 62. Laiks – 120 minūtes (jo angliski un mēs neesam angļi. Angļiem ir 90).

 Eksāmena % sadalījums:

  • 40% – BPMN notācijas zināšanas – ko nozīmē kurš elements, kā raksta scenārijus, kā veidojas modelis u.tml.
  • 15% ir par BMM jeb Business Motivation modeling – stratēģiskā domāšana, vīzija, misija, taktika. Jebkas, ko uzņēmumā darām, ir attiecināms (saistīts) ar kādu augstāku mērķi, kā to nodrošināt.
  • 30 % – pamatzināšanas, pamatjēdzieni, kā arī – kas ir biznesa procesi, kā veidojas organizācija, kā rodas un veidojas procesi, apakšprocesi, darbības principi, plūsmas
  • 15% – augstā (virspusējā) līmenī – pārvaldības ietvari, kvalitāte, mērījumi

Image

Domāšana

Vairākkārt tika runāts, ka šīs nav „plikas zīmēšanas” apmācības, bet ir vairāk – domāšana, pieeja, attieksme. Visam pamatā ir mērķis, uzņēmuma mērķa esamība un virzība uz to ir uzņēmuma brieduma indikators. Izslēdzam pieeju ”daru šito tāpēc, ka man tas jādara”. Tā vietā: „daru tāpēc, ka tā sasniedzu mērķi X”. Skaidri saprotams, kāds process, kas to sāk, kas beidz, ko dara, kāds rezultāts, kādi nosacījumi.

Subjektīvā daļa – vai es to gribu?

Pašlaik nezinu. Ohohoo, protams, patiktu pamosties ar šīm zināšanām (un sertifikātu :-) ), bet šobrīd kārtoju Oracle programmēšanas sertifikāciju, tāpēc par šo padomāšu ne gluži rīt, bet nākamgad. Diagrammas zīmēju, bet jāatzīst, tās ir stipri vienkāršas, salīdzinot ar BPMN 2.

Ko pavisam noteikti varu apgalvot: brīdī, kad man BPMN ieinteresēs pa īstam, es iešu uz šiem kursiem, jo BMPN 2 standarts uz 508 lapām ir, piedodiet autori, bet miega zāļu piesātināts. Tāpēc labāks veids, kā to apgūt, būs kursi un ikdienas lietošana.

Caurskrienot BPMN 2 – bildītēs

Notācija ir ļoti bagāta – daži piemēri (vairākas no šīm es nezināju) – nokopēju no sagūglētiem slaidiem par BPMN 2 tutorial:

Image

Diagrammu piemēri:

Image

 

Image

 

Image

Horeogrāfijas piemērs (arī nokopēju no sagūglētiem slaidiem par BPMN 2 tutorial)

Image

Eksāmena jautājumu piemēri

 Image

 

Image

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.

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.

%d bloggers like this: