Гранттар мен субсидияларды басқару жүйесі: мәртебелер мен төлемдер

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

Гранттар мен субсидияларды басқару жүйесі тек өтінім қабылдау үшін емес. Ол бүкіл циклді бір жерде сақтауы тиіс: өтініш беру, тексерулер, экспертиза, комиссия, келісімшарт, төлемдер және міндеттемелерді жабу. Біртұтас контур болмаса, процесс поштаға, Excel-ге және мессенджерлерге шашылады, және кейбір сәтте қарапайым сұраққа — «өтініш қай қадамда және неге кідіріп тұр?» — тез және дәл жауап беру мүмкін болмай қалады.

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

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

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

Рөлдер мен құқықтар: жүйеде кім не істей алады

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

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

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

Әдетте проблемадан сақтайтын практикалық қолайлылық ережелері:

• Жеке деректер мен банк реквизиттері тек оларды нақты пайдаланатындарға ғана ашық.
• Өтінім берушінің файлдарын қосуға және ауыстыруға комплектілік бекітілмейінше ғана рұқсат; бекітілгеннен кейін — тек өзгерту сұрауы арқылы және себеппен.
• Эксперт комиссияның дауысын аяқтамай тұрып, дауыс беру нәтижесін көрмеуі тиіс.
• Протоколдар бақылаушы және аудит үшін оқу режимінде қолжетімді болуы тиіс, ал түзетулер реттелген процедура арқылы және нұсқалармен ғана жүргізіледі.
• Құқықтармен және құжаттармен жасалған кез келген әрекет уақытпен, қолданушы мен негізбен журналға жазылады.

Осылайша бақылаушыларға түсінікті: кім шешім қабылдады, қандай деректермен, және ешкім құжаттар мен сандарды байқамай алмастыра алмады.

Минималды деректер моделі: не сақтау қажет, ойдан шығармау үшін

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

Өтінім карточкасы өзіндік болуы тиіс. Егер мәлімет жеткіліксіз болса, қызметкерлер «шындықты» хаттар мен кестелерде сақтай бастайды, және сіз бірегей дереккөзді жоғалтасыз.

Өтінім карточкасына ақылға қонымды минимум:

• бағдарлама/конкурс және кезең (жыл, этап, қабылдау терезесі)
• сұралатын сома, валюта, болжамды төлем кезеңдері
• өтінім беруші (ұйым/жеке тұлға), ЖСН/БСН, контактілер, мекен-жай
• төлемдерге арналған банк реквизиттері және төлем алушы (қажет болса өзгеше)
• қосымшалар: файлдар тізімі, құжат түрі және жүктеу датасы

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

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

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

Өтінім статус схемасы және өту ережелері

Негізгі статустар тізбегі

Өтінім статустары қолмен жазылған белгілерге айналмауы үшін тізбек сквозной болу керек: Черновик (өтінім берушіде) → Подано → На проверке комплектности → Требуются уточнения → Допущено → На экспертизе → На комиссии → Одобрено немесе Отказ → Договор → К выплате → Выплачено → Закрыто.

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

Өту және ерекшеліктер

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

Жұмысқа арналған негізгі ережелер:

• Өтінім беруші Черновик → Подано күйіне тек автотексеру арқылы жіберуі мүмкін (міндетті өрістер, файл форматтары, қол қою, келісімдер).
• Оператор На проверке комплектности → Допущено күйіне чек-лист 100% жабылса ғана ауыстырады; әйтпесе — Требуются уточнения күйіне түсіріп, түсініктеме мен мерзім қояды.
• Эксперт тек На экспертизе күйінде жұмыс істейді; бағалар комиссияға тапсырылғаннан кейін бекітіледі және өзгертілмейді.
• Комиссия хатшысы На комиссии → Одобрено/Отказ тек отырыстың протоколы және құрамы бар кезде ауыстыра алады.
• Қаржылық жауапты тұлға Договор → К выплате күйіне қол қойылған келісімшарт пен реквизиттер бар кезде ауыстырады; К выплате → Выплачено — төлем расталғаннан кейін.

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

Жекелеген тармақтарды айқын жасаңыз: Заявитель отозвал (Подано/Требуются уточнения-тен), Апелляция (Отказ-тан кейін), Решение аннулировать (Одобрено-дан кейін) — барлық жағдайда міндетті негіз және журналға жазылуы керек.

Комплектілікті тексеру: чек-листтер және доработкалар сценариі

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

Чек-лист бір жалпы емес, әр бағдарламаға арналған болуы тиіс. Ол нақты және тексерілетін: қандай құжаттар міндетті және кім қол қояды, файл форматтары мен өлшемі, анықтамалардың жарамдылық мерзімі (30/60/90 күн), реквизиттер талаптары (банк, IBAN, төлем тағайындауы), ерекше жағдайлар (филиалдар, сенімхат, бірлескен өтінімдер) үшін ережелер.

Әрі қарай автотексерулерді қосыңыз, сонда уақытты анық нәрселерге жоғалтпайсыз. Көбіне бұл негізгі өрістердің толтырылуы, ЖСН/БСН сәйкестігі, банк реквизиттерінің базалық валидациясы, дубльдерді іздеу (бір өтінім беруші — бір бағдарлама — бір кезең), анықтамалардың жарамдылық мерзімін тексеру.

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

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

Минимум ретінде тіркеңіз: дата мен уақыт, жауапты адам, қорытынды (принято/на доработку), сәйкессіздіктер тізімі категориялармен (критикалық/түзетілуі мүмкін) және түсініктемелер. Бұл «неге өтінім әрі қарай жіберілмеді?» деген сұраққа болжамсыз жауап береді.

Экспертиза және бағалау: критерийлер мен нәтижелерді қалай сақтау

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

Нәтижелер файлдар мен хат алмасуға айналмас үшін критерийлерді құрылымдалған деректер ретінде сақтаңыз. Әр конкурс үшін шкалалар, салмақтар және шектер орнатып, жүйе өтінімнің минималды талаптан өтетінін көрсете алады.

Әр критерий бойынша сақтау пайдалы: шкала түрі (0–5 немесе иә/жоқ) және диапазон, салмақ пен шек (бар болса), балл және эксперттің түсініктемесі (төмен бағада міндетті), бағалауға қосымша файлдар (қажет болғанда), уақыт және автор.

Мүдделер қақтығысы — бұл жай ғана «тұтқа» емес, қатынау ережесі. Эксперт нақты өтінім бойынша өзіне шеттету жариялай алуы тиіс, және жүйе сол өтінімге балл қою мен дауыс беруді бұғаттауы тиіс. Өзін-өзі шеттету себебін қысқа мәтін түрінде сақтау жеткілікті, жеке деректерді артық қоспай.

Итогтарды жинауды автоматтандыру керек: жалпы рейтинг формула бойынша есептеледі (баллдарды салмақтармен, шектер мен дөңгелектеу ережелерімен есептеу). Егер «әлеуметтік әсер» критерийі бойынша шек 3-тен төмен болса, өтінім жалпы балл жоғары болса да «шекадан төмен» деп белгіленуі мүмкін. Жүйе отырысқа дайындық ретінде рейтингілік кестені және материалдар пакетін дайындайды: баллдар, түсініктемелер, өзін-өзі шеттетулер және талқылауды қажет ететін өтінімдер тізімі.

Комиссия: шешімдерді протоколдеу және дауыс берулерді бекіту

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

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

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

Протокол өз алдына дербес құжат болуы керек, «комментарий» өрісі емес. Негізгі құрам:

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

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

Төлем кезеңдері: комиссия шешімінен бастап міндеттемелерді жабуға дейін

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

Төлем тізбегінің типтік үлгісі

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

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

Қаржыландыруды растайтын кезеңде лимиттерді бақылауды қосыңыз: бағдарлама жалпы бюджеті, келісімшарт бойынша қалдық, бұрын төленген транштар. Лимиттен асыру әрекеті жүйеде блокталып, себебін көрсетуі тиіс (мысалы, «бағдарлама бойынша қалдық 1 200 000, сұралған 1 500 000»).

Тоқтату, қайтару және құжаттар

Төлем формалды негіздер бойынша тоқтатылуы тиіс және тарих сақталуы керек. Қатты себептер: уақытылы аралық есеп берілмеген; келісімшарт талаптары бұзылған; ақшаларды қайтару немесе бұрын төленген соманы есепке алу қажет.

Әр транш үшін құжаттар тізімі мен олардың тексеріс статусы сақталуы тиіс: төлем өтінімі, шот, акт/жабушы құжаттар, төлем растамалары, қайтару туралы хат (бар болса). Мысалы: екінші транш тек KPI бойынша есеп қабылданғаннан және акт қол қойылғаннан кейін қолжетімді. Әйтпесе статус «приостановлено» болып тұрып, жүйе төлем жіберуге рұқсат бермейді.

Оқиғалар журналы және аудит: тексеруге қалай қамтамасыз ету

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

Әр операция үшін пайдаланушы мен рөлі, дата және уақыт (уақыт белдеуімен), объект (өтінім, файл, төлем), әрекет, ескі және жаңа мәндер, сондай-ақ себеп немесе түсініктеме тіркелсін. Себеп әсіресе қолмен түзетулер, ерекшеліктер және доработкалар үшін маңызды.

Тексеруді қиындататын негізгі оқиғалар:

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

Файлдар жиі әлсіз жер болады. Метадеректерді сақтаңыз (түрі, авторы, жүктеу уақыты, чек-лист тармағына байланысы) және бүтіндік бақылауын (хэш). "Файлды ауыстыру"ға рұқсат бермеу өте маңызды: оның орнына жаңа нұсқа қосып, ескі нұсқаны аудит үшін қол жетімді қалдырыңыз.

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

Жүйені жобалау және енгізу қадамдары

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

Әдетте жылдам нәтиже беретін реттілік:

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

Мысал: сіз шағын бизнеске арналған бір субсидия бағдарламасында пилот іске қосасыз. Бірінші аптада өтінім берушілер жиі бірдей құжатты ұмытып жүктейді. Демек чек-листке ескерту қосылады, ал «На доработке» статусына міндетті өріс — «қайтару себебі» шаблондарымен енгізіледі.

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

Жоба кезінде жиі кездесетін қателер мен тұзақтар

Ең жиі сәтсіздік себебі — статустар арқылы процестің логикасын алмастыруға тырысу. Осылайша 20–30 жағдай пайда болады, бірақ ешкім қайдан қайға өтуге болатынын түсінбейді, және біртіндеп өтінімдер ілініп қалады, ал қызметкерлер жүйені қоңырау мен хат арқылы айналып өтеді.

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

Процесті әдетте не бұзады

• Нұсқалар жоқ: құжаттар қайта жүктеледі, протоколдар артқа қарай түзетіледі, және комиссияның нақты не қарағанын дәлелдеу мүмкін емес.
• Рөлдер араласты: бір қызметкер комплектілікті тексеріп, содан кейін төлемді бекітеді.
• Мерзімдер бақылаусыз: этаптарға дедлайндар, еске салғыштар және эскалациялар жоқ, сондықтан просрочки байқалмай жиналады.

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

Егер жүйені жүйелік интегратормен бірге жасасаңыз (мысалы, GSE.kz), алдын ала қай рөлдердің бірлесуге болмайтынын және қандай жазбалар қол қойылғаннан кейін өзгертілмеуі тиіс екенін келісіңіз.

Іске қосар алдында қысқа чек-лист

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

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

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

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

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

Ақырында, аудит және іске қосу:

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

Мысал сценарий: өтінімнен екі транш төлемге дейін

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

Жібергеннен кейін өтінім «Подана» статусын алады. Чек-лист бойынша автотексеру кемшілікті тауып, өтінімді «Требует доработки» күйіне ауыстырады. Өтінім берушіге хабарлама келеді, және өтінім карточкасында себеп: «X анықтама қосылмаған», күн, тексеруді кім бастағаны (пайдаланушы немесе ереже) және түзету мерзімі жазылады.

Анықтаманы жүктегеннен кейін өтінім беруші «Отправить повторно» батырмасын басады. Жүйе статусын «На проверке комплектности» деп өзгертеді, маман не өзгергенін көріп комплектілікті растайды. Статус «Принята к экспертизе» болады.

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

Содан кейін субсидия бойынша төлемдер іске қосылады:

• Транш 1 — келісімшартқа қол қойылғаннан және «Договор заключен» статусына келгеннен кейін.
• Транш 2 — «Отчет подтвержден» статусына және комиссия шарты орындалғаннан кейін.

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

Келесі қадамдар: әзірлеу және эксплуатацияға дайындық

1–2 апталық қысқа «нулевой спринттен» бастаңыз: грант берушіден талаптар жинаңыз (конкурс ережелері мен есептілік), бухгалтериядан (проводкалар, құжаттар, КБК және лимиттер), сонымен қатар қауіпсіздік қызметінен (құқықтар, жеке деректерді сақтау, журналдау). Көп жағдайда осы үш блок шетінде пилотта жүйе бұзылады.

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

Дайындық жоспары:

• Өтінімнен міндеттемелерді жабуға дейінгі процестерді сипаттау, соның ішінде ерекшеліктер (доработкалар, бас тарту, қайтарып алу).
• Рөлдер мен құқықтар матрицасын бекіту, аудит әрекеттерін қоса.
• Интеграциялар тізімі: есеп жүйесі, қазынашылық реестрі, ЭЦП, хабарламалар, анықтамалар.
• Файлдарды сақтау және протоколдарды сақтау мерзімдеріне қойылатын талаптарды дайындау.
• Тест сценарийлері мен қабылдау критерийлерін анықтау.

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

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