Жүйедегі әмбебап келісімдер: статустар мен эскалациялар

«Әмбебап келісімдер» деген не және неге маңызды

Жүйедегі әмбебап келісімдер — бір механизм арқылы әр түрлі құжаттарды: өтініштер, келісімшарттар, шоттар, кадр бұйрықтары, ИТ өзгерістері, сатып алуларды өткізу тәсілі. Мұнда кодты немесе логиканы емес, параметрлерді өзгертесіз: кім келіседі, қандай тәртіппен, қандай мерзімдер, үзіліс болғанда не істеу керек.

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

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

Жеткілікті түрде әр түрлі бағыттарда (жабдықтау, ИТ инфрақұрылым, сервис жұмыстары) келісімдер жүріп жатқан ұйымда әмбебап тәсіл болжамдылық береді. Қызметкерлер статустарды түсінеді, басшы кешігулерді көреді, қауіпсіздік қызметі әрекеттер тізбегін алады.

Жақсы нәтиже былай көрінеді: бір қозғалтқыш, процестер параметрлер арқылы беріледі. Онда алдын ала жалпы ережелер анықталған — біртұтас статустар моделі мен қайтару себептері, ролдер бойынша мерзімдер мен эскалациялар, тексерістері бар бөлек қол қою кезеңі, жауапкершілік пен тарих жоғалтпай делегирование. Жаңа құжат түрін қосу — логиканы қайта жазу емес, баптау тапсырмасы болады.

Негізгі нысандар: құжат, маршрут, қадам және тапсырма

Келісімді әртүрлі процесс үшін қайта жинап шықпау үшін алдымен қарапайым нысандар мен олардың шекаралары туралы келісіңіз. Сол кезде жаңа құжат түрлері мен маршруттарды ядроны бұзбай қосуға болады.

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

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

Минималды объектілер жиыны әдетте мынадай:

• Құжат: мәліметтер мен процестің қорытындысы.
• Маршрут: келісім схемасы мен ережелері.
• Қадам: логикалық кезең (мысалы, юристтер, қаржы, қауіпсіздік).
• Тапсырма: нақты адамның орындауы қажет іс.
• Шешім: тапсырма бойынша нәтиже (кеңейтімнен, қабылданды, кері қайтарылды) және түсініктеме.

Тапсырма мен құжаттың күйлерін айыру маңызды. Тапсырма жаңа, орындауда, орындалған, мерзімі өткен, делегирленген болуы мүмкін. Осы уақытта құжат барлық қажетті тапсырмалар аяқталғанға дейін «Келісуде» күйінде қалуы немесе бір бас тартудан кейін «Доработкада» күйіне өтуі мүмкін.

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

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

Статустар: түсінікті модельді қалай жобалау керек

Әмбебап схема «ерекше жағдайлар жиынтығына» айналмас үшін статустар нысан мен қадамның нақты күйлерін сипаттауы тиіс, адамдар мен бөлімдерді емес.

Құжаттың минималды статустары

Қысқа жиыннан бастаңыз және оны сақтау керек. Әр рөлге («юристтерде», «ҚТ-да», «бухгалтерияда») жеке статус қосудан бас тартыңыз — модель тез тарқайды және оны ұстау қиынға түседі.

Көбінесе жеткілікті статустар: Қаралама, Келісуде, Қол қою күтілуде, Доработкада, Болдырылмаған, Аяқталған. Олар негізгі сұраққа жауап береді: құжат қозғала ма, әрекет күтілуде ме немесе жабық па.

Қадам мен тапсырмалардың статустары

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

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

Шешімдердің тексерілуін қамтамасыз ету үшін әрбір өткелмен бірге сақтаңыз:

• себеп (түсініктеме немесе себеп коды)
• кім бастады (пайдаланушы, жүйе, делегат)
• іс-әрекет уақыты
• источник (веб, мобильді, интеграция)

Мысал: мектепке ПК сатып алу өтініші «Келісуде» болды, кейін «Доработкада» қайтарылды себебі — «сауда ұсынысы жетіспейді». Қайтаруды бастады — басшы, жүйелік еске салғыш емес.

Маршруттар: тізбектілік, параллель және ережелер

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

Қадам түрлері және оларды қалай біріктіруге болады

Қадам — келісушілерге арналған «пакет» тапсырмалар. Практикада бірнеше типтік вариация жеткілікті, оларды бір маршрутта араластыруға болады:

• Тізбекті қадам: тапсырмалар бірінен кейін бірі келеді.
• Параллельді қадам: тапсырмалар барлығына бірден шығады, қадам аяқталу ережесі бойынша жабылады.
• Аралас қадам: алдымен параллельді (мәселен, эксперттер), содан кейін тізбекті (басшылар).
• Шартты қадам: шарт орындалғанда ғана қосылады (сома, категория, тәуекел).

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

Қадамды аяқтау ережелері

Параллельді қадамдардың «жабылып қалмауы» үшін алдын ала не есептелетінін белгілеңіз:

• Барлығы: әрқайсысынан жауап керек.
• Көбі: M ішінен N жеткілікті.
• Бір шешуші: қадам белгілі рөлдегі адам келіссе аяқталады.
• Қоспа ереже: шешуші + кем дегенде бір эксперт.

Мысал: сервер сатып алғанда алдымен ИБ мен эксплуатациядан визалар параллель жиналады, содан кейін қаржы директоры мен басшы тізбекті түрде қарайды. Жаңа құжат үшін басқа маршрут шаблонын таңдайсыз, арнайы логика қоспай.

Мерзімдер (тайм-ауттар): уақыттар, еске салулар және мерзім өту ережелері

Мерзімдер келісімнің тұрып қалмауы үшін қажет. Оларды әрбір процесс ерекшелігі емес, модель бөлігі ретінде қарастырған дұрыс.

SLA екі деңгейде ыңғайлы белгіленеді. Қадам SLA — кезеңге жалпы мерзім (мысалы, «Қаржылық келісім 2 жұмыс күні ішінде аяқталуы керек»). Тапсырма SLA — қадам ішіндегі нақты орындаушыға мерзім (мысалы, әрбір екі келісушіге 1 жұмыс күн беріледі). Осылайша параллельді келісімдер мен ауыстыруларды басқару оңайырақ.

Көбінесе үш тип мерзім жетеді: алу мерзімі (орындаушы тапсырманы N сағат ішінде қолға алуы керек), шешім мерзімі (шешімді дедлайнға дейін қабылдау), және қол қою мерзімі (электронды қол қою немесе басқа форма үшін бөлек уақыт).

Белгілеу маңызды: мерзім өткенде жүйе не істейді. «Алдымен жұмсақ, кейін қатал» тәсілі жұмыс істейді: еске салу, содан кейін эскалация; автошешім — тек төмен тәуекелдер үшін және айқын ережеге сай. Қауіпсіздікке қатысты қадамдар үшін процесс шешім шыққанша тоқтатылуы мүмкін.

Мысал: мемлекеттік органға сервер сатып алу өтініші. Тапсырманы қолға алу 4 сағат, шешім қабылдау 1 жұмыс күні. Мерзім өткенде жүйе бірінші еске салады, 2 сағаттан кейін эскалация жасайды. Сома лимиттен жоғары болғандықтан автошешім жоқ.

Жұмыс уақыты емес кезеңді қарапайым тәсілмен сақтау жақсы: елге тән жұмыс уақыты күнтізбесін сақтау және мерзімдерді «жұмыс уақытына» есептеу. Дедлайн демалысқа немесе мерекеге түссе, оны ең жақын жұмыс күніне сол уақытта жылжыту керек.

Эскалациялар: мәселені қолмен бақылаусыз қалай көтеру

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

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

Эскалация спамға айналмас үшін шектері мен аралықтарын қойыңыз: бірінші эскалация мерзімнен кейін N сағат/күннен кейін, қайталану белгілі интервалдан жиі емес, бір тапсырмаға максимум 1–3 эскалация. Соңғыдан кейін — автоотказ немесе міндетті басшы шешімі.

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

Мысал: жобаға арналған сервер сатып алу өтініші қаржы қадағалау қадамына іліп қалса. 24 сағаттан кейін еске салу, 48 сағаттан кейін тапсырма қаржы басшысына өтеді, бастапқы келісушіге тапсырма эскалəndгені туралы хабарлама келеді.

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

Қол қою: айқын ережелері бар бөлек кезең

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

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

Қол қою түрлерін бір қадамның баптаулары арқылы қолдау ыңғайлы: интерфейсте растау (ішкі регламенттер үшін), КЭП/ЭЦП (заңды мәні бар құжаттар үшін), серверлік қол қою — сервис нақты ережеге сәйкес қол қоятын режим.

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

Дәлел базасы үшін кем дегенде сақтау керек: күн мен уақыт (уақыт белдеуімен), кім және қандай рөлмен қол қойғаны, нұсқа идентификаторы мен мазмұн хэші, тексеріс нәтижесі және бас тарту себебі, сертификат деректері (қолданылса), техникалық із (құрылғы, IP, сессия идентификаторы).

Делегирование (өкілеттік беру): бақылауды жоғалтпай алмастыру

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

Көбінесе екі режим бөлінеді. Қолмен делегирование — қызметкер немесе басшы алдын ала қол қойып, тапсырманы береді. Автоматты делегирование HR жүйесіндегі жоқтық кестесіне немесе күнтізбеге сәйкес іске қосылады.

Шектеулерді ашық қою керек, әйтпесе қауіптер мен түсініспеушілік пайда болады: делегирование тек бөлім ішінде немесе рөл бойынша болсын (мысалы, «басшының орынбасары»), басталу мен аяқталу датасы міндетті, «араға беру» шектелсін, қаржылық лимиттерге бөлек ереже (лимиттен жоғары — тек басшы ғана).

Алда бар тапсырмаларға не істеу керек — нәзік мәселе. Практикада екі амал болуы мүмкін: «жаңа тапсырмалар автоматты түрде орынбасарға барады» және «ағымдағы тапсырмалар аударылады немесе бастапқы орындаушыда қалады». Шұғыл процестерде (сервер сатып алу сияқты) әдетте ағымдағы тапсырмалар да аударылады, бірақ тарих сақталады: кім тағайындалған және кім шешім қабылдаған.

Пайдаланушы интерфейсі мен есепте делегирование көрініп тұруы тиіс: «Шешім Иванова атынан Петровтың орынбасары ретінде қабылданды (өкілеттік 15.02-ге дейін)».

Процесс барысында өзгерістер: қайтарып алу, доработка, қайталау

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

Инициаторға қайтарып алу көбіне қайтарым нүктесіне дейін рұқсат етіледі. Бұл көбінесе қол қою басталғанға дейін немесе кем дегенде бір келісуші шешім қабылдағанға дейінгі кезде. Қайтарып алу кезінде із жойылмауы тиіс: белсенді тапсырмалар «болдырылмаған» күйге өтеді, себеп пен кім қайтарып алғаны тіркеледі, орындалған шешімдер тарихта қалады.

Ескерту бойынша доработка басқарылатын цикл сияқты жұмыс істейді: «қайтарылды» → «инициатор түзетті» → «қайта келісім». Көшірмелерді көбейтпеу үшін құжат нұсқасын (номер немесе хэш) сақтаңыз және қайталануды нақты нұсқаға байлаңыз. Солай не өзгергені көрінеді.

Жартылай келісімді сақтау мүмкін, бірақ ережелер бойынша. Егер өзгерген бөлім қаржылық шарттарды қозғаса, қаржы мен юристтерді қайта жіберу логикалық, ал техникалық келісімдер күшінде қалуы мүмкін. Өрістер X өзгерсе қайта келісім талап етілетіні туралы белгі жақсы.

Шексіз қайтарулардан сақтану үшін тәртіп қойыңыз: доработка санына шек (мысалы, 2–3), қайтарудың себебі нөмірленген сөздіктен таңдалсын + түсініктеме, негізгі өрістер өзгермей қайта іске қосуға тыйым, «N қайтарудан кейін — процестің иесіне эскалация» ережесі.

Мысал: сервер сатып алу өтініші толық негіздеме жетіспеушілігіне байланысты қайтарылды. Инициатор есепті қосып, қайталап жіберді. Техникалық қадам сақталды, ал қаржылық қадам қайтадан басталды, себебі сома мен мерзімі өзгерді.

Әмбебап келісімдерді енгізуде жиі жіберілетін қателіктер

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

Тыптік қателіктер:

• Құжат статустары мен тапсырма статустарын бір тізімге араластырады. Құжат өз өмірін (қаралама, келісуде, қол қойылды), тапсырмалар өз өмірін (тағайындалған, орындауда, аяқталған, мерзімі өткен) ұстану керек. Оларды біріктірсеңіз, нақты не болғаны анық болмайды.
• Кодта ерекшеліктер көптеп пайда болады: «келісімшарттар үшін осылай», «сатып алу үшін өзгеше», «ИТ өтініштері үшін тағы басқа». Маршруттар, ережелер, мерзімдер мен эскалациялар конфигурацияда болуы тиіс, if-else тарауларында емес.
• Жүйе автошешімдерді айқын логсыз қосады. Егер жүйе мерзім бойынша өздігінен «келістім» деп белгілесе, пайдаланушы: кім, қашан және қандай ережеге сай болғанын көруі керек.
• Нұсқалар жоғалады. Бұл көбіне қол қоюда пайда болады: құжатқа өзгерістер енгізіп, ескі нұсқаны қол қойған жағдайлар.
• «Қазір кім жауапты?» деген сұраққа жауап жоқ. Делегирование, қызметкер ауысуы және параллельді қадамдар кезінде бұл өте маңызды.

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

Іске қоспас бұрын қысқа чек-лист

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

1) Статустар: бір минут ішінде түсіндіре ала ма?

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

Статустар тапсырма мен құжаттың күйін көрсететін болсын, эмоцияны емес. «Келісуде» мен «Қол қою күтілуде» қажет, ал «Петровта орындауда» сияқты көрсеткіштер орындаушы ретінде қалсын, статус емес.

2) Мерзімдер және эскалациялар: тыныштыққа не болады?

Анық мерзімдер, еске салулар және салдарлар болуы тиіс. Тек еске салу көп көмектеспейді.

Тез өту сұрақтары:

• Бірінші еске салу қашан және кімге барады?
• Мерзім өткенде не болады: автоэскалация, орындаушыны ауыстыру немесе блоктау ма?
• Эскалацияны кім алады және тарихта не көрсетіледі (күн, себеп, кім жауап бермеген)?
• «Мерзімі өткен» пен «қорғау үшін тоқтатылған» (мысалы, деректер күту) арасын ажыратуға бола ма?

3) Қол қою және делегирование: тарихтағы іздер

Қол қою екі сұраққа жауап беруі керек: не нәрсеге қол қойылды (нұсқа, файлдар жиыны) және қалай расталды (қол қою түрі, уақыт белгісі, тексеріс нәтижесі).

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

Мысал процесс: өтініштен қол қоюға дейін

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

Өтініштің статус тізбегі барлық құжат түрлері үшін бірдей болуы мүмкін:

• Қаралама
• Келісуде
• Доработкада
• Қол қоюда
• Қол қойылды немесе Болдырылмаған

Маршрут мысалы: алдымен бюджет (қаржы), содан кейін ИБ, кейін юристтер, соңында құжат басшыға қол қоюға жіберіледі. Әр тапсырмаға 48 сағат мерзім қойылған. 24 сағат өткенде еске салу жіберіледі, 48 сағатта мерзім өткен деп есептеліп эскалация іске қосылады.

Эскалация былай көрінеді: ИБ келісушісі 48 сағат жауап бермесе, тапсырманың статусы «Мерзімі өтті» болады, жаңа тапсырма оның басшысында (немесе дежурныйда) ашылады. Сол уақытта бастапқы шешім блокталады, екі қарама-қарсы жауап болмас үшін.

Делегирование жалпы ережілерге сай болады. Егер юрист демалыста болса, орынбасары іске қосылады: жүйе тапсырманы орынбасарға қайта тағайындайды және тарихты сақтайды — кім бастапқы орындаушы болған және кім шешім қабылдаған.

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

Келесі қадамдар: логиканы қайта жазбай енгізу

Келісімге келісіп бастаңыз. Қай статус финал саналады, кім процессті бастай алады, кім келіседі, кім қол қояды және қандай оқиғалар процесті алға жылжытады (жасалды, жіберілді, қайтарылды, мерзімі өтті, эскалирован) — осыны сипаттаңыз.

Практикалық енгізу жолы:

• Рөлдер мен қадам түрлерін (келісім, тексеру, қол қою, танысу) және өту ережелерін бекіту.
• Табиғаты әр түрлі 2–3 пилот процесс жинау: қарапайым (1 келісуші), параллель (2–3 келісуші), қол қою мен эскалация бары.
• Пилоттарды нақты жағдайларда өткізу: демалыс, сатып алу, жүйеге қол жеткізу, келісімшарт.
• Әмбебаптығын тексеру: жаңа процесс баптаулар арқылы қосыла ма, қосымша статустар мен код өзгертусіз бе.
• Метрикаларды енгізу: мерзімі өткендердің үлесі, қадамның орташа уақыты, доработкаға қайтарулар саны.

Даудың алдын алу үшін материалдар дайындаңыз: рөл матрицасы, қадам түрлері бойынша SLA және еске салу ережелері, эскалация ережелері, делегирование саясаты, пилоттар үшін маршрут шаблоны және қолдаусыз болатын ерекшеліктер тізімі.

Прототипті бірден бірнеше тарапқа көрсеткен дұрыс: бизнеске (пайдаланудың ыңғайлылығы), ҚБ-ға (құқылар мен аудит), юристтерге (қол қою мен сақтау), ИТ-ға (справочниктер мен есептік жазбалармен интеграциялар).

Егер енгізу кезінде жүйелік интеграция қажет болса, кейде интеграторды тарту оңайырақ. Мысалы, GSE.kz (gse.kz) жүйелік интеграция және инфрақұрылымдық шешімдермен айналысады — бұл келісімдер ИТ-процестермен, сатып алулармен және қолдаумен тығыз байланысты болса пайдалы болуы мүмкін.