CRM/ERP үшін UAT (пайдаланушы қабылдауы): сценарийлер мен қабылдау

CRM/ERP енгізудегі UAT не шешеді

UAT (пайдаланушы қабылдауы) бір сұраққа жауап береді: жүйе нақты жұмыстануға дайын ба, әлде жоқ па. Бұл код сапасының немесе техникалық тесттердің жиынтығы емес. Мұнда бизнес компанияда қабылданған тәртіппен процестер орындалатынын және нәтижені қауіпсіз түрде пайдаланушыларға беруге болатынын растайды.

Фокус айрықша. IT көбінесе тұрақтылыққа, қателерге, интеграцияларға және жылдамдыққа қарайды. Бизнес негізінен мәнге қарайды: шот беруге бола ма, тапсырысты өткізуге бола ма, өтінішті жабуға бола ма, есеп қалыптастыру дұрыс па және сол арқылы бөлімнің жұмыс ережелері бұзылмай ма.

UAT іске қосқаннан кейін жиі көрінетін тәуекелдерді жауып қояды:

• процестің маңызды қадамдары нақты практикамен сәйкес келмеуі
• деректер толтырылады, бірақ әрі қарай пайдаланылмайды (немесе басқа жерге түседі)
• рұқсаттар сондай бапталған, жұмыс тұрып қалады
• есептер басшылардың көрінісімен сәйкес келмейді
• пайдаланушылар айналып өту жолдарын табады да Excel-ге оралады

UAT нәтижесі — «багтар тізімі» емес, басқарушылық шешім: қабылдаймыз, шектеулермен қабылдаймыз немесе доработкаға жібереміз. Бұл шешім алдын ала келісілген қабылдау критерийлеріне негізделуі тиіс.

Қабылдау критерийлері болмаса, тестілеу тез дауға айналады. Біреу: «жұмыс істейді, батырманы бассаң — статус өзгереді». Басқа біреу: «жұмыс істемейді, өйткені статус басқа және басқа уақытта өзгереді». Мысалы, CRM-де менеджер «Келісім» кезеңін тек КП тіркелгеннен және лимит тексерілгеннен кейін ғана көруі тиіс. Егер ереже критерий ретінде жазылмаса, әркім «дайын» дегенді өз бетінше түсіндіреді.

UAT қатысушылары және жауапкершілікті бөлу

UAT тек кім шешім қабылдайтыны және кім көмектесетінін анық білсе ғана жұмыс істейді. Бизнес жүйені қабылдайды. Енгізу тобы жағдайды қамтамасыз етеді, баптауларды түсіндіреді және мәселелерді түзетеді, бірақ бизнестің орнына «емтихан тапсыруы» тиіс емес.

Нәтижені тапсырушысы әдетте екі варианттың бірі: процесс иесі (сату, сатып алу, қойма) немесе жүйеден ең көп әсер алатын бөлім басшысы. Ол қандай нәтиже «сәтті» екенін формулирлайды және шешімді басшылық алдында қорғайды.

Кілтті пайдаланушылар — жүйеде күнделікті жұмыс істейтін адамдар. Олардың міндеті — өз рөлінде сценарийлерді өтіп, нақты емес жерлерді адал тіркеу. Уақыт туралы алдын ала келісу маңызды: UAT әдетте «кездесулер арасында» жасалса, сәтсіз болады.

Енгізу тобы (соның ішінде аналитик) көмектеседі:

• жұмыс жағдайларын түсінікті сценарийлерге және тесттік деректерге айналдыру
• баптаулар мен регламенттер бойынша қалай жұмыс істеуі тиіс екенін түсіндіру
• ақаулар мен сұрақтарды жедел талқылау
• нәтижелерді тіркеу тәртібін ұстау

Бірақ енгізушілер бизнесті алмастырмауы тиіс. Егер сценарий «өткен» деп саналса тек аналитик айналып өту жолын айтып өтсе, бұл процесс немесе интерфейс қайта өңдеуді қажет ететін сигнал.

Финалдық қолтаңба тағайындалған бизнес-спонсорға қойылады (көбінесе процесс иесі немесе бағыт жетекшісі). Негіз — орындалған сценарийлер, қабылдау критерийлерінің орындалуы және бизнес қазір қабылдауға келісетін белгілі шектеулер тізімі. Егер жүйелік интегратормен жұмыс істесеңіз, бұл ережені жазбаша бекітіңіз: кім қабылдайды, кім түзетеді, кім түзетуді растайды.

Қамту анықтау: нені тексереміз, нені шегінен шығарамыз

Қамту команда бірдей нәрсені тексерсін және «бес жылдық барлық есептерді тексерейік» сияқты дауларға уақыт жұмсамасын үшін қажет. Қамтуды бір бетте бекіту ыңғайлы: нені тексереміз, қандай деректерде, қандай рөлдерде және не дайын саналады.

UAT өтуі міндетті процестер тізімінен бастаңыз — олар іске қосу күні пайдаланылатын болады. Әдетте:

• сатулар: лид -> сделка -> шот/шарт -> жабылу
• сатып алу және қойма (ERP үшін): өтініш - тапсырыс - қабылдау - тапсырма
• қаржы: құжаттар, төлемдер, статус сәйкестігі
• сервис: өтініш тіркеу - тағайындау - орындау - жабу
• қолжетімдіктерді басқару: кілтті рөлдер және типтік құқықтар

Одан кейін қандай интеграциялар мен есептер тексерілетініне шешім қабылдаңыз. Қарапайым ереже: пайдаланушының осы жердегі және дәл қазір шешіміне әсер ететіндерді қосыңыз. Мысалы, сатуда пошта мен телефония интеграциясы, шоттар үшін бухгалтериямен алмасу, BI-ға шығару — тек 2–3 негізгі витриналар үшін.

UAT-қа не кірмейтінін дереу жазып қойыңыз, егер бөлек келісілмесе. Көбінесе шегінен тыс қалады: жүктеме тесті, ақпараттық қауіпсіздік тексерісі, сақтық көшірлеу, техподдержка және мониторинг процестері.

Сценарийлер тарқамауы үшін ереже ұстаңыз: бір сценарий — бір тексерілетін күтілетін нәтиже. Мысал: «Менеджер сделка жасайды және шот шығарады» — күтілетін нәтиже дәл бір факт болуы тиіс: «шот статус 'Жіберілді' алды және шоттар реестрінде пайда болды'."

Қалай бюрократиясыз UAT сценарийлерін жинау керек

Сценарийлерді «нөлден» емес, бизнестің күнделікті қолданатын нәрселерінен жинау оңай. 45 минуттық 2–3 қысқа кездесу өткізіңіз: сатулар, сервис, қаржы, қойма (бар болса). Күнделікті әрекеттерді, жиі болатын ауырсынуды және күннің немесе айдың соңында керек есептерді талқылаңыз.

Сценарий көздері әдетте көзге түседі: регламенттер мен нұсқаулықтар, ағымдағы есептер мен шығарылымдар, қолдау сұраулар тізімі, жоба талаптары. Пайдалы тәсіл: пайдаланушылардан қазір уақыт немесе ақша үнемдей алмайтын 5 жағдайды атауларын сұраңыз. Осыдан UAT ядросы шығады.

Сценарийлердің өсіп кетпеуі үшін бір қарапайым шаблон қолданыңыз:

• мақсат
• қадамдар (5–10 әрекет, артық егжей-тегжейсіз)
• тесттік деректер (қандай өрістер мен мәндер қажет)
• күтілетін нәтиже
• ескертпелер (шектеулер, рөлдер, «тұзақтар»)

Тесттік деректерді бірге әзірлеу тиімді: бизнес шынайы мысалдар береді (клиенттер, номенклатура, типтік сомалар), енгізу тобы оларды тесттік ортаға жүктеуге көмектеседі. Деректерді бір жерде сақтаңыз және ережелер қойыңыз: деректер жиынтығының бір иесі, анық атаулар, жеке деректерді қолдануға тыйым салу, егер бөлек келісілмеген болса.

Шығарылымдарды ұмытпаңыз. «Идеал» үрдістен бөлек, әр сценарийге 1–2 қате жағдай қосыңыз: тапсырысты болдырмау, қайтару, клиент дублі, толық емес деректер, жауапты өзгерту.

Әдетте пайдалы минималды жинақ:

• басынан аяғына дейінгі сквозные тізбектер (лид -> сделка -> документ -> оплата)
• 2–3 критикалық есеп (күн, апта, ай)
• рөлдерге сай қолжетімдіктер
• процесс жұмыс істемейтін интеграциялар
• пайдаланушы қатесі үшін бір сценарий (өріс толтырылмаған, қате сома)

Осылайша бастыны тексеріп, үлкен папкалар мен жүздеген тест-кейстерге уақыт жұмсамайсыз.

Бизнес-жауапты тағайындау: рөлді қалай таңдап, бекіту

UAT-та бизнес-жауапты — процесс атынан «иә, біз осылай жұмыс істейміз» немесе «жоқ, бұлай болмайды» деген адам. Бұл рөл болмаса, тест тез ажыратылған ескертулер жиынына айналады, және ешкім шешім қабылдамайды.

Тағдайды «ең белсенді» адамнан емес, күнделікті жұмысты шынайы басқаратын және соңғы сөзді айту құқығы бар адамнан таңдау керек. Көбінесе бұл топ жетекшісі, аға маман немесе процесс иесі (мысалы, воронка мен сделкалар үшін сату жетекшісі).

Кандидаттың жарамдылық белгілері:

• процесті және ерекшеліктерді білетін, тек «идеал жолды» ғана білмейтін
• шешім қабылдап, компромистерді тіркей білетін
• UAT кезеңінде қолжетімді (уақыт алдын ала бөлінген)
• күту нәтижелерін қарапайым сөздермен айта алатын, әзірлеме детальдарына кірмейтін
• нәтиже үшін жауап беруге дайын, тек «даярлаймыз» деп шектелмейтін

Қанша бизнес-жауапты қажет екенін жоба көлеміне қарай шешеді. Практикада әр негізгі процесс (сату, сатып алу, қойма, сервис) бойынша минимум бір адам тағайыналады. Үлкен жобаларда бизнес тарапынан жалпы координатор тағайындайды, ол процесстер қиылыстарын шешеді.

Өкілеттіктерді жазбаша бекіткен дұрыс: жоба бойынша бұйрық/нұсқау, процесс тізімі мен мерзімдері бар хат немесе UAT бастау протоколы.

UAT қадамдық жоспары: бастапқадан қабылдауға дейін

UAT хаосқа айналмас үшін жұмыс тәртібін бекіту және ережелерді жолында өзгертпеу маңызды. Тестілеу бөлек ортада, анық қолжетімдіктермен және тексеріс кезеңінде «мұздатылған» жүйе нұсқасында жүргізілгені дұрыс.

Жұмыс жоспары:

• орта мен есептік жазбаларды дайындау (рөлдер, құқықтар, тесттік деректер); UAT уақытында нұсқаны келісусіз жаңартпау
• қысқа инструктаж өткізу (20–30 минут): сценарийлер қайда, қадамдарды қалай тіркеу, дефект нені есептеу, не жақсарту сұрауы екенін айқындау
• сценарийлерді орындап, бірыңғай статус қою: «өткерілді», «өтпеді», «блокталған»
• күнделікті синхрон (10–15 минут): не өтті, не блоктайды, жауапты кім және қандай мерзімде блокерді шешеді
• түзетулерден кейін қайта тексеру: алдымен «құлаған» сценарий, содан кейін әсерленген көрші процестерді (регрессия бақылауы)

Шынайы өмірде мысалы: сату менеджерінің сценарийі «сделканы жасау - шот шығару - төлемді өткізу» бухгалтерия модуліндегі рөл себебінен блокталады. Блокер дереу тіркеледі, жауапты тағайындалады. Түзетуден кейін сценарий қайтадан жүргізіледі және құқықтардың келісімін бұзбағанына көз жеткізу үшін қосымша тексеріледі.

Финалдық қадам — қорытынды протокол. Онда әдетте: өткен сценарийлер пайызбен, ашық дефектілер тізімі (салмақтылығы мен мерзімі), қандай нәрсе шектеулермен қабылданды және нақты шешім: қабылдаймыз, түзетулерден кейін қабылдаймыз немесе іске қосуды кейінге қалдырамыз.

Қабылдау критерийлері: қалай құру, келісу және өлшеу

Қабылдау критерийлері — жүйе дайын ба дегенді шешетін келісім. Олар «ұқсас жұмыс істейді» деген жалпылама пікірден сақтайды және дау туындайтын сәттерде тез шешуге көмектеседі.

Жақсы критерий әрқашан тексерілетін болуы тиіс. Ол не істелетіні, қандай деректерде, қандай нәтижені дұрыс санайтынын және оны қалай өлшейтінін айқындауы керек. «Ыңғайлы», «жылдам», «дұрыс» сияқты сөздер мысалдарсыз көбіне қақтығыс тудырады.

Қабылдау критерийлерін қалай жазу керек

Ыңғайлы формат: әрекет + шарттар + күтілетін нәтиже + рұқсат етілген ауытқу.

• функция: «Менеджер міндетті өрістермен сделка жасайды; клиенттің ИИН-ы жоқ болса сделка сақталмайды; жүйе түсінікті қате көрсетеді»
• деректер: «Миграциядан кейін 100% актив клиенттерде уникалды ИИН бар; ИИН бойынша дубль жоқ; 10 таңдамалы карточка негізгі полелер бойынша бастапқы көзбен сәйкес келеді»
• есептеулер: «Шот сомасы = жолдар сомасы - жеңілдік + ҚҚС; 5 тест мысалында айырмашылық 0»
• интеграциялар: «CRM-тен шыққан шот бухгалтерия жүйесіне 5 минут ішінде түсуі тиіс; төлем статусы қайтарылып отырады; қателер журналға жазылады»
• шектеулер: «30 қолданушы бір уақытта 1 сағат жұмыс істесе жүйе құламайды; клиент карточкасын ашу 3 секундтан аспауы тиіс»

Сату үшін мысал: критерий «шот қалыптасады» емес, «шот үлгі N бойынша қалыптасады, реквизиттер анықтамалықтан тартылады, сома ережелер бойынша есептеледі, файл қателіксіз ашылады» — осылай нақты жазу керек.

Қабылдау шегі: не іске қосуды бөгеп тастайды

Қай ақаулар критикалық екенін алдын ала келісіңіз. Көбінесе критикалық — негізгі процесті бұзады, деректерді бүлдіреді немесе мерзімді жабуға кедергі келтіреді.

• критикалық: тапсырысты немесе шотты өткізе алмайсыз, деректер жоғалады, сандар қате, міндетті интеграция жұмыс істемейді
• критикалық емес: опечатка, форма әдемілігі, есепті жақсарту ұсынысы

Критерийлерді бір құжатқа жазып, процесстер иелерімен қол қойыңыз. Сол кезде UAT қорытындысы фактілермен өлшенеді: орындалды не жоқ, плюс белгілі шектеулер мен мерзімдер.

Нәтижелерді тіркеу: тест журналдары, дефектілер және өзгеріс сұраулары

Егер UAT нәтижелері поштада жүрсе, бақылау жоғалады: не тексерілген, не сынған, не жай «өзгерткіміз келді» — бәрі шатасады. Бір жалпы журнал керек, онда әр сценарийдің статусы және келесі әрекет көрінеді.

Журнал үшін минималды өрістер:

• сценарий мен қадам
• күтілетін және нақты нәтиже
• дәлелдер (скрин, шығару, құжат нөмірі)
• тексерушінің жауаптысы (бизнес) және түзетуге жауапты (енгізу тобы)
• статус және дата (Табылды, Істеуде, Ретестке дайын, Қабылданды)

Ары қарай дефектілерді қарапайым классификацияға бөлу туралы келісу керек, сонда әр істі басымдылықтар туралы таласпаңыз:

• критикалық: процесс тоқтайды
• маңызды: процесс орындалады, бірақ шығындармен (есептеулердегі қателер, құқықтар, интеграция сәтсіздігі)
• косметика: нәтижеге әсер етпейді

UAT созылмас үшін түзету мерзімдері мен растау ережелерін қойыңыз: қашан түзетеді, қашан ретест тағайындайды және финалдық «қабылданды» кім қояды. Мысалы: критикалықтер — 1–2 күнде түзету және сол күні ретест; маңыздысы — келесі спринтте; косметика — backlog-қа.

Ақау мен өзгеріс сұрауын шатастырмау маңызды. Дефект — жүйе келісілген талаптар мен қабылдау критерийлеріне сәйкес істемегені. Өзгеріс сұрауы — «енді басқалай істейік» деген ұсыныс, оны бөлек change request ретінде белгілеу және бөлек бағалау дұрыс.

Пайдалы артефакт — белгілі шектеулер тізімі. Мысалы, бизнес бірінші нұсқада есепті күнде бір рет қолмен жасайтынын саналы түрде қабылдайды — бұл іске қосуға кедергі емес. Ең бастысы — бұл шешім жазылып, қол қойылуы тиіс.

UAT-та жиі болатын қателер және олардан қалай сақтану

UAT-тың ең жиі сәтсіздігі — багтар емес, ұйымдастыру ақауы. Тестілеудің мақсаты — процестердің шынайы деректер мен рөлдерде жұмыс істейтінін растау, тек экран ашылатынын тексеру емес.

1. Өте жалпы сценарийлер. «Клиент жасау» деп жазып қойсаңыз, кім болса өзіне қарай тестілейді. Рөл, нақты деректер (мысалы, ИИН, келісім түрі, жеңілдік) және нақты нәтиже қажет (карточка жасалды, статус өзгерді, құжат қалыптасты).

2. Дайындықсыз бастау. Қолжетімділіктер, анықтамалықтармен тесттік база және қысқа инструкциялар болмаса, қатысушылар уақытын айналып өтулерге жұмсайды. Бастамас бұрын бірнеше күн кейін созған жөн.

3. Анықталмаған шешімдер. Бизнес-жауаптылар тағайындалмаса, әр ескерту талқылауға айналады. Әр процесс үшін финалдық сөз айтуға иесі болу керек.

4. Бақылаусыз түзетулер. Өзгерістер нұсқасы тіркелмей және қайта тексерусіз енгізілсе, UAT нәтижелері салыстырылмайды, багтар қайта оралады.

5. Қабылдау дизайн туралы дауқа айналады. UAT-та бастысы — процестің жұмыс істеуі: тапсырысты өтініштен жіберуге дейін өткізу, шотты жабу, есеп алу.

Мысал: менеджер міндетті өріс болмағаннан сделканы өткізбей отырса — бұл дефект. «Түйме оң жақта болу керек» — бұл өзгеріс сұрауы және қабылдауға бөгет болмауы тиіс.

UAT басталар алдындағы қысқа чек-лист

Бастамас бұрын жүйені тек «айналдырып көру» емес, іске қосу туралы шешім қабылдауға дайын екеніңізге көз жеткізіңіз.

Тестілеу шеңберін тексеріңіз. Егер қамтуда «лид - сделка - шот» тізбегі болса, онда телефония мен бухгалтерия интеграциялары қосылған немесе әдейі шегерілген және бұл жазылған болуы керек.

Іске қосар алдындағы минималды тексеріс:

• қамту келісілген: процестер, рөлдер және интеграциялар тізімі бекітілген
• сценарийлер дайын: қадамдар, тест деректері және күтілетін нәтиже түсінікті тілде бар
• бизнес-жауаптылар тағайындалған: әр процесс бойынша нәтиже растайтын адам бар және критерийлерді біледі
• орта дайын: қолжетімділіктер мен рөлдер берілген, тесттік пайдаланушылар жасалған, тесттік деректер толтырылған, сыртқы қызметтер жұмыс істейді немесе саналы түрде өшірілген
• нәтижелерді тіркеу және мәселелерді шешу ережелері айқын: журнал кім жүргізеді, дефект қалай сипатталады, түзетулер мерзімі, соңғы протоколдың күні мен форматы

Егер бір пункт та болса «сарғайып тұрса», UAT әдетте пікір таластарға айналады. Бір күн дайындыққа арнаған жеңілірек, чем апта бойы қайта тапсыруға бару және пайдаланушыларға қолмен айналып өтуге мәжбүр ету.

Мысал сценарий: CRM енгізудің сатулар мен сервиске арналған UAT

Контекст: компания жабдық сатады және сатып алғаннан кейін клиенттерге қызмет көрсетеді. UAT-та сатулар бөлімі, сервис қызметі, бухгалтерия және бағыт жетекшісі қатысады (ол процесс «дұрыс жұмыс істейді» деп растайды). Тексерілетін нәрсе — интерфейстің әдемілігі емес, негізгі операциялардың айналып өтусіз орындалуы.

Критикалық сценарийлер қысқа әңгімелер түрінде ыңғайлы жазылады, нақты нәтиже көрсетілген:

• лид воронкаға түседі, жауапты тағайындалады, шыққан көзі және келесі қадамы тіркеледі
• сделкадан шарт пен шот құрылып, содан соң отгрузка жүзеге асырылып, статустар синхронды өзгереді
• өтініш тіркеледі, классификацияланады, орындаушы тағайындалады және пікірмен жабылады
• қайтару/рекламация отгрузкаға байланады және сервис пен бухгалтерияда көрсетіледі
• жетекші воронка бойынша есептерді, сервис жүктемесін және мерзімнің бұзылуын қарайды

Қабылдау домендер бойынша: сатуда — сату жетекшісі (немесе кілт менеджер), сервисте — сервис басшысы (немесе аға инженер), бухгалтерия құжаттар мен интеграциялардың дұрыстығын растайды.

Критерийлерді өлшенетін түрде жазыңыз: «өтініш 5 минут ішінде қате өрістерсіз жабылуы тиіс», «сделка мен отгрузка статустары сәйкес келуі тиіс», «айлық сату есебі бақылау шығаруымен сәйкес келеді», «серивсте мерзімдегі тапшылықтар мен себептері көрінуі тиіс».

UAT нәтижесі — сценарийлер тізімі «қабылданды/қабылданбады» статусымен, қабылданған шектеулер тізімі (қолмен уақытша орындалатын нәрселер) және іске қосқаннан кейінгі доработкалар жоспары, иелері мен мерзімдері көрсетілген.

UAT-тен кейін не істеу: іске қосу, бақылау және қолдау

UAT-тен кейін қабылдау пакетін жинау маңызды: шешім протоколы, дефектілер тізімі және белгілі шектеулер (қазір қалай жұмыс істейтіні және неліктен бұл рұқсат етілетіні). Бұл алғашқы күндердегі дауларды азайтады.

Содан кейін іске қосу жоспарын келісіңіз: бәріне бірден қосамыз ба, әлде бөлімдер бойынша кезең-кезеңмен өткіземіз бе, алғашқы апталарда қандай өзгерістер жасауға болады. Оқыту бөлек келісілсін: рөлдер бойынша қысқа сессиялар (сату, бухгалтерия, қойма) бір үлкен тренингтен гөрі тиімдірек болады.

Бақылаудың әділ болуы үшін алғашқы 2–3 аптаға 3–4 метрика таңдаңыз. Олар процестің жұмысын көрсетуі тиіс: критикалық қателер саны, қолдау сұраулары саны, негізгі операцияның орындау уақыты (тапсырыс рәсімдеу немесе өтініш жабу), айналып өтуға кеткен операциялар саны.

Қолдау мен жақсартуларды да алдын ала сипаттаңыз: сұрақтар үшін бір арна, басымдылық ережелері, алғашқы күндердегі қысқа талқылаулар, шешімдерге жауаптылар және түзетулер шығару жоспары.

Жобаға инфрақұрылым міндеттері (серверлер, жұмыс орындары, 24/7 қолдау) қосылса, олар бір серіктеспен жабылса ыңғайлы. Мысалы, GSE.kz өндіруші және жүйелік интегратор ретінде инфрақұрылым мен қолдау қызметінің бір бөлігін өз мойнына алып, жоба командасын UAT, іске қосу және пайдаланушыларды қолдау арасында бөлмеуі мүмкін.