ТОиР бойынша мердігерлік жұмыстарға өтініштерді автоматтандыру: үдеріс моделі

Неліктен ТОиР бойынша мердігерлік жұмыстарға өтініштерді автоматтандыру керек

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

Басқа даулардың басты себебі — жоспар мен факт арасындағы сәйкессіздік. Өтініште бір нәрсе жазылған, ТЗ-де басқаша, сметада үшінші нұсқа, ал фактіде төртінші. Бұл бәрі бір жүйеде бекітілмесе, дау тез жеке нәрсеге айналады: кім уәде етті, кім келісім берді, кім рұқсат берді, кім қабылдады.

Көбіне жоғалатын нәрсе құжаттар емес, олардың тарихы. ТЗ-дің үш нұсқасы, сметаның екі нұсқасы және ескертулермен хат алмасу бар, бірақ қандай нұсқа допуск пен қабылдауға негіз болғанын анықтау қиын. Нәтижесінде актілер мен КС-2/КС-3 бойынша есептеу кешігеді, ал сапа немесе мерзім үшін ұстап қалулар саудаға айналады.

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

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

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

Терминдер мен үдеріс шекарасы: ТОиР-ге не кіреді, не кірмейді

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

Негізгі терминдер қарапайым тілмен

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

Бастапқыда үш типті бөлу пайдалы:

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

Жобалық тапсырмалар әдетте капиталдық жобалардың ережелеріне бағынады. Оларды ТОиР ағынымен араластырса, бюджет пен мерзімді бақылау тез жоғалады.

Негізгі құжаттар және олардың мағынасы

ТЗ (техникалық тапсырма) — қандай нәтиже қажет екенін және қандай талаптар бойынша көрсету керек екенін сипаттайды. Смета — неше тұратынын және бағаның қалай құралатындығын көрсетеді. Рұқсат — объектіде жұмыс бастауға рұқсат (қауіпсіздік, қолжетімділік, наряд, инструктаж). Қабылдау — нәтижені тексеру: жұмыс істей ме, талаптарға сай ма, ескертулер бар ма. Актілеу — орындалған жұмыстарды құжаттау (көбінесе КС-2/КС-3 немесе ішкі актілер), бұл төлеу мен міндеттемелерді жабуға мүмкіндік береді.

Басқарылатын үдеріс үшін қажетті минималды жинақ:

• өтініш — сипаттама, объект, приоритет және жауапты тұлғалар;
• ТЗ немесе ақау ведомосты (не істеледі және неге);
• смета немесе келісілген баға, кезеңдерге байланған;
• рұқсат құжаты (наряд/рұқсат/журнал);
• қабылдау актісі және орындалған жұмыстар актісі (төлем және жабылуға арналған).

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

Үдеріс моделі қадамдар бойынша: өтініштен бастап ұстап қалуларға дейін

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

Үдеріс логикасы: 5 кезең

Практикада үдерісті үлкен блоктарға жинау ыңғайлы, ал ішкі мәліметтерді (ТЗ және сметаның нұсқалары, хаттамалар, файлдар) сақтау керек.

• Инициирлеу: өтініш инициатордан — объект, себеп, приоритет және қалаулы мерзімдер.
• Жұмысты анықтау: ТЗ — жұмыс көлемі, материал талаптары, сапа критерийлері, фото, өлшеулер, схемалар.
• Қаржы және шешімдер: смета — позициялар, өлшем бірліктері, бағалар, материалдар, салықтар; кейін маршруткалар бойынша келісім және лимиттер, келіспеушіліктер мен нұсқалар тіркеледі.
• Рұқсат және орындау: наряд немесе рұқсат, еңбекті қорғау, жұмыс аймағы, рұқсат терезесі және уақыттық шектеулер.
• Қабылдау және есептеулер: фактілік көлемдер, ескертулер, актілеу (КС-2, КС-3), сапа мен мерзімге байланысты ұстап қалулар.

Өтініштен кейін маңызды кезең — «істегіміз келеді» сатысынан «не және қанша үшін келісілді» сатысына өту. Сондықтан ТЗ мен смета нұсқалы болуы керек: әр түзету авторымен, күні және себебі көрсетіледі, ал келісім нақты нұсқаға қатысты жүреді.

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

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

«Орындау фактісі» мен «қаржылық фактіні» бөліп жазған пайдалы. Қабылдау фактілік көлем мен сапаны растайды, ал актілеу — ұстап қалуларды есепке алып төленетін соманы көрсетеді.

Утриманиялар ашық есептелуі үшін жүйеде әдетте тіркеледі:

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

Ережелер алдын ала бекітілсе, қабылдау чек-лист бойынша тыныш тексеріске айналады, сөз жүзінде емес.

Рөлдер, жауапкершілік және шешім қабылдау нүктелері

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

Негізгі рөлдер әдетте: тапсырыс беруші (жабдық иесі немесе бастама бөлімше), ТОиР қызметі (техникалық үдеріс лидері), жабдықтау (сатып алу және келісімдер), қаржы (бюджет пен төлемдер), ОТиПБ (рұқсаттар және қауіпсіздік), мердігер (орындау және көлемді растау).

RACI матрицасын кезеңдер бойынша сипаттау ыңғайлы:

• Өтініш және ТЗ: тапсырыс беруші қажеттілік пен бастапқы деректер үшін жауапты (R), ТОиР қызметі техникалық бөлімін дайындайды (R), тапсырыс берушінің басшысы приоритет пен қажеттілікті бекітілмек (A), ОТиПБ қауіптер бойынша кеңес береді (C), қаржы жоспарланған шығындар туралы хабардар етіледі (I).
• Смета және мердігерді таңдау: мердігер есеп дайындайды (R), жабдықтау сатып алу бөлігін жүргізеді (R), қаржы лимит пен төлем шарттарын бекітеді (A), ТОиР қызметі нормалар мен көлемдер бойынша кеңесші болады (C), тапсырыс беруші мерзімдер туралы хабардар етіледі (I).
• Рұқсат, қабылдау, актілер: мердігер орындайды және растайтын құжаттарды береді (R), ТОиР қызметі көлем мен сапаны қабылдайды (R), тапсырыс беруші қабылдауды бекітеді (A), ОТиПБ қауіпсіздік талаптарының орындалуын растайды (C), қаржы төлем үшін деректер алады (I).

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

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

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

Қандай деректер қажет: минималды нысандар мен байланыстар схемасы

Автоматтандыру «скан-қоймаға» айналмауы үшін минималды деректер моделін бастапқыда анықтаңыз. Оның мақсаты — бір өтінішті нақты объектімен, келісілген жұмыс көлемімен (жоспар) және шын мәнінде қабылданған/төленгенмен (факт) байланыстыру.

Көбіне бес негізгі нысан жеткілікті, қалғаны кейін қосылады:

• Өтініш: номер, инициатор, мердігер, объект/площадка, приоритет, жоспарлы мерзімдер, статус.
• Объект/жабдық: инвентар номері, орнату орны, түйін/агрегат, критикалығы, өтінішке байланысы.
• ТЗ және смета (нұсқаларымен): нұсқа, дата, автор, өзгеріс себебі, соңғы құн, НДС, қосымшалар.
• Жұмыс жоспары (позициялар): позиция коды, жұмыс түрі, бірлік, жоспарлы көлем, баға, смета позициясына байланыс, ТЗ/сметаның нұсқасына сілтеме.
• Факт, қабылдау және актілеу: әр позиция бойынша фактілік көлем, орындау күні, қабылдау нәтижелері, ақаулар, құжаттар (КС-2/КС-3 немесе баламалар), ұстап қалулар.

Байланыстарды осылай салу пайдалы: жоспар мен факт бір «якорь» — жұмыс позициясының коды бойынша сәйкес келсін. Ол жоспар-факті салыстыруды қолмен сәйкестендірмеуді қамтамасыз етеді. ТЗ/сметаның нұсқасын сақтау маңызды: егер смета қайта келісілсе, ескі позициялар жаңа нұсқаға «қозғалмауы» тиіс.

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

Файлдарды түсініп сақтау: әр файлға түрі (фото, схема, протокол, скан-хат), дата, автор және нақты нысанға байлау — ТЗ нұсқасына, рұқсатқа, қабылдауға немесе актіге. Сонда дауларды тексеру минуттарда, күндер емес болады.

Жоспарлы және фактілік көлемдерді салыстыруға арналған деректер жиынтығы

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

Минимум бес кесте Excel-де де бастап, кейін жүйеге көшкенде де жарайды:

Work_Plan(
  request_id, work_item_code, uom,
  qty_plan, price_plan,
  date_start_plan, date_end_plan
)

Work_Actual(
  request_id, work_item_code, uom,
  qty_fact,
  date_start_fact, date_end_fact,
  crew, comment
)

Acceptance(
  request_id, work_item_code,
  qty_accepted, qty_rejected,
  defect_type, rework_required, remarks
)

Acts(
  request_id, act_id, act_type,
  amount_plan, amount_fact,
  sign_date_contractor, sign_date_customer,
  status
)

Withholdings(
  request_id, withholding_id,
  reason, method,
  base, amount,
  release_rule
)

Кестелердің логикасы қарапайым: Work_Plan — көлем мен баға бойынша күтуді анықтайды, Work_Actual — орындаған фактіны тіркейді, Acceptance — не қабылданғанын және не кері қалғанын көрсетеді, Acts — жұмыстарды актілермен байланыстырады (КС-2, КС-3 немесе ішкі акт), Withholdings — ұстап қалулар мен оларды шешу ережелерін сақтайды.

Жоспар мен фактіні дау тудырмай қалай салыстыру

Есептер қателеспеуі үшін ережелер алдын ала бекітілуі керек:

• Өлшем бірліктері (uom) сәйкес болуы тиіс. Егер мердігер м2 әкелсе, ал жоспар м.п. болса, түрлендіру кестесі мен негіздеме қажет.
• Дөңгелектеу: мысалы, көлем үшін 0.01, сомалар үшін 2 ондық. Бір ереже барлық есептерге бірдей болуы тиіс.
• Бөліп қабылдау: жоспар-факт салыстыруды qty_accepted (қабылданған) бойынша жүргізіңіз, qty_fact (орындалған) бойынша емес. Қайтарылған qty_rejected ретінде қалсын.
• Позицияны жабу: work_item_code позициясы жоспарлы көлемге жетсе немесе көлем өзгерісі (қосымша келісім/өтініш өзгерісі) бекітілсе жабық саналады.

Кішкене мысал

План: work_item_code = "RPL-001", uom = "шт", qty_plan = 10, price_plan = 50 000. Факт: мердігер qty_fact = 10 есеп берді, бірақ қабылдау 2-ні ақаудан қайтарды: qty_accepted = 8, qty_rejected = 2, rework_required = "иә". Акт қабылданған көлем бойынша (8) есептеледі. Сапа бойынша ұстап қалуды қабылданған негізден пайыз ретінде есептеп, тек қайта қабылдау сәтінде шешуге болады.

Автоматтандыруды енгізу: қарапайым қадамдар

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

Дайындық: алдымен келісіп, кейін баптау

Алдымен өтініш статустары мен көшу шарттарын сипаттаңыз. Мысал: қаралама —> келісімде —> рұқсат берілді —> орындалды —> қабылдауда —> жабылды. Кім статус жылжыта алатынын және қандай өрістер толтырылуы керектігін дереу белгілеңіз.

Содан кейін 3–5 ТЗ және смета шаблондары жасаңыз — жұмыс түрлері бойынша (электрика, КИПиА, механика, құрылыс). Шаблон жұмыстар құрамын, өлшем бірліктерін және минималды құжат жиынтығын көрсетіп отыруы тиіс.

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

Келісім маршруттарын баптаңыз. Ерекшеліктер көп болса, қолмен жұмыс көп болады. Маршруттар мен сомалар бойынша лимиттерді алдын ала орнатқан жөн: X-ке дейін — бір бекітуші, одан жоғары — екіншісі, критикалық жұмыстар бөлек. Бюджет бақылауын қосыңыз (лимит, мақсатын анықтау, шығын орталығы).

Іске қосу: фактіні орындау барысында жинау

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

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

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

ТОиР мердігерлік жұмыстарында жиі кездесетін қателер мен тұзақтар

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

Жиі кездесетін проблемалар:

• Жоспар мен факт әртүрлі сөздермен сипатталған. Жоспарда «насос жөндеу» болса, фактіде «тазалау», «дебаг», «белдіктерді ауыстыру» сияқты басқа терминдер жазылады. Нәтижесінде жоспар-факт сәйкес келмей, дау терминология төңірегінде өрбиді.
• ТЗ мен смета нұсқалары сақталмайды. Келісілгеннен кейін бірдеңе өзгертілген және ескі нұсқа сақталмаған болса, бекітілген нені және қандай баға бойынша дәлелдеу мүмкін емес.
• Бөліп қабылдау ережелері анықталмаған. Ұзақ жұмыс болғанда (апта, ай) кезеңдер болмаса бәрі ілініп қалады: мердігер акт сұрайды, тапсырыс беруші аяқтауды күтеді, даулы көлемдер жиналады.
• Рұқсат жүйеден тыс рәсімделеді. Наряд-рұқсаттар, инструктаждар, ыстық жұмыстарға рұқсаттар бөлек қалса, жұмыс фактісі рұқсатсыз басталған болуы мүмкін және жауапкершілікті анықтау қиынға соғады.
• Удержаниялар қолмен есептеледі. Кестелерде пайыздар, есеп базалары мен даталар бойынша қателер жиі болады; мердігермен дау болу ықтималдығы жоғары.

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

Практикалық мысал: өтініште «10 м құбыр ауыстыру» деп жазылған, ал фактіде 8 м жасалып, қосымша екі арналық бөлінген. ТЗ/смета нұсқалары мен бөлшектеп қабылдау ережелері болмаса, актілеу саудаға айналуы мүмкін. Автоматтандыру тек сол ережелер үдеріске енгізілген кезде ғана көмектеседі.

Өтінішті жабуға дейінгі жедел тексерістер

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

Алдымен өтініштің табылатынына және контексті қалпына келтірілетініне көз жеткізіңіз. Нөмір және объектінің байланысы болуы тиіс: площадка, цех, желі, жабдық бірлігі (инвентарлық нөмір немесе актив коды). Егер объект «шамалап» көрсетілсе, жоспар-факт есептерінде қателіктер пайда болады.

Содан кейін негіз құжаттарды тексеріңіз. ТЗ мен смета бекітілген, нұсқалары бар (мысалы, v2 12.03) және кім қашан келіскені анық көрсетілген. Егер жолда өзгерістер болған болса, олар бөлек нұсқа ретінде тіркелуі керек, артқа қарай түзету болмайды.

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

Қысқа бақылау тізімі:

• объект пен жабдық нақты көрсетілген;
• ТЗ мен смета бекітілген, нұсқалар мен жауапты тұлғалар бар;
• әр позицияда жұмыс коды мен өлшем бірлігі бар;
• факт сол позициялар бойынша енгізілген, даталар мен растайтын материалдар бар;
• қабылдау қабылданған/қабылданбаған және себеп көрсетілген.

Соңында ұстап қалуларды тексеріңіз. Олар ережеге сай есептелген болуы тиіс, нақты акт пен позицияға байланған. Мысалы, акт бойынша бояу 80% қабылданды деп есептелсе, ұстап қалу дәл сол позицияға сілтеп көрсетілуі қажет, «барлық акт бойынша» деген жалпы формула емес.

Мысал: бір ТОиР өтініші — ТЗ-ден актілер мен ұстап қалуларға дейін

Площадкада сорғы агрегаты Н-17 тоқтап қалды: діріл жоғары, тығыздағыштан ағып жатыр. Ауыстыру командасының басшысы мердігерге тапсырма беру үшін өтініш жасайды және критикальдық деңгейін көрсетеді: тоқтау бүкіл желіге әсер етеді.

ТЗ ақаудан және өлшенетін көлемнен құралады. Өтініште: не бұзылғаны, қандай жұмыстар қажет, қандай материалдарды тапсырыс беруші береді және қабылдау критерийлері көрсетілген. Қабылдау критерийлері өлшенетін: діріл белгіленген деңгейден аспауы, ағын болмауы, сорғы 8 сағат жүктемеде жұмыс істеуі. Мерзім: мердігер рұқсат алғаннан кейін 3 күн.

Мердігер сметаны ұсынады, ол келісімнен және түзетулерден өтеді. Позициялар мысалы (1-нұсқа, кейінгі нақтылаудан кейін финалдық нұсқа):

• Түйінді бұзу және дефектация (1 компл)
• Торцевой тығыздағышты ауыстыру (1 шт)
• Подшипниктерді ауыстыру (2 шт)
• Агрегатты центрлеу (1 компл)
• Іске қосу және сынау (8 нормо-сағат)

Келісімнен кейін рұқсат рәсімделеді: жұмыс күндері, жауапты тұлғалар, тоқтату терезесі, ОТиПБ талаптары. Факт журналда жүргізіледі: ауысымдар, объектідегі адамдар, орындалған көлем, тоқтаулар. Өтініш карточкасына «алды/кейін» фотосуреттер мен өлшеу нәтижелері қосылады.

Жоспар-факт негізгі көлемдер бойынша қарағанда ыңғайлы:

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

Содан кейін актілеу: КС-2/КС-3 қабылданған көлемге дайындалады. Мерзім 1 күн бұзылды, сондықтан келісімшарт шарттарына сәйкес жұмыстар құнының 5% ұстап қалынды. Удержание-ны қайтару шарты дереу бекітілді: 30 күн ішінде қайталап ағып немесе діріл расталмаса ұстап қалу қайтарылады.

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

Жақсы ТОиР автоматтандыруы «әдемі экрандармен» емес, шешім қабылдауға көмектесетін есептер арқылы байқалады. Егер ТЗ, смета, келісімдер, рұқсаттар мен актілер бойынша деректер біркелкі жиналса, қай жерде мерзімдер мен ақша жоғалып жатқанын тез көруге болады.

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

Осы есептер жұмыс істеуі үшін бірнеше метриканы келісіп, тұрақты ұстау керек:

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

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

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

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

Егер сіз Қазақстанда болсаңыз және осыны өз үдерісіңізге бейімдегіңіз келсе, GSE.kz (gse.kz) жүйелік интегратор және жабдық өндіруші ретінде ПК және сервер таңдау, енгізу және инфрақұрылымдық қолдау бойынша көмектесе алады, осылайша ТОиР үдерісі қолмен жұмысқа тәуелді болмайды.