ПК жаңартқаннан кейінгі қолдау сұрауының құнын есептеу: әдістеме

ПК жаңартудан кейінгі өтініш құнын неге есептеу керек

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

Сандар есепке алынбай тұрмау үшін қажет емес. Олар нақты жағдайға қарай не тиімдірек екенін көрсетеді: жөндеу ме, ауыстыру ма, әлде дооснащение ме. Екі құрылғы бірдей жиілікпен бұзылуы мүмкін, бірақ біреуін диагностикалау, сирек запчастьтар немесе ұзақ келісімдер себебінен 3 есе көбірек уақыт кетуі мүмкін. Осы жағдайда шешім әдетте жөндеуде емес, модельді ауыстыруда, кепілдікті кеңейтуде немесе критикалық компоненттердің шағын қорын ұстауда жатыр.

Қолдану құнын әдетте бюджетті және сервис сапасын тікелей әсер ететін шешімдер қабылдау үшін есептейді: ескі модельдерді қашан дереу шығару, қандай құрылғылар алу, қандай запчастьтар қорында ұстау, SLA қалай орнату, қай жерде пайдаланушыларға оқу қажет және қай жерде образдар мен баптауларды стандартизациялау керек.

Маңызды: «обращение» деп нені жатқызатыныңыз туралы алдын ала келісіп алыңыз, сонда «бұрын» мен «кейін» арасындағы салыстыру адал болады. Бірдей объектілерді есептеңіз: тикет, звонок, чат, выезд, қайталау. Сондай-ақ қайталануға ереже орнатыңыз (мысалы, «сол себеп бойынша 7 күн ішінде қайталанған») және инциденттерді өзгерістер сұраныстарынан айыра біліңіз. Әйтпесе парк тек есептеу әдісіне байланысты нашар немесе жақсы көрінуі мүмкін.

Есептеудің терминдері мен шекараларын айқындау

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

Негізгі терминдер

Қолдау сұрауы — пайдаланушының сервис-дескімен байланысы: звонок, хат, жүйедегі тикет.

Инцидент — пайдаланушыға кедергі келтіретін бұзу немесе жұмыстың нашарлауы (ПК қосылмайды, қол жеткізу жоғалды, қосымша ілініп қалады).

Сұраныс — бұзылусыз жоспарлы өтініш (бағдарламаны орнату, рұқсат беру, деректерді көшіру).

Қайталау дегенді бөлек бекітіңіз. Практикада қайталама ретінде бір себеппен бір терезе ішінде (мысалы, 7 немесе 14 күн) пайда болған тикетті санау ыңғайлы, тіпті жаңа тикет ретінде тіркелсе де.

Жүзбе-ережелер көмектеседі:

• 1 обращение = 1 тіркелген тикет
• 1 инцидент/сұраныс = тикет ішіндегі жұмыс түрі
• қайталама = бірдей симптом және бірдей нысан (ПК/пайдаланушы) белгіленген мерзімде

Өлшеу периоды және салыстыру бірліктері

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

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

Шекаралар: не есепке кіреді

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

Шекараларды бекітпесеңіз, жаңа ПК енгізу жұмыстары қолдаудың мойнына түсіп, нәтижені бұрмалауы мүмкін.

Қандай деректер жинау керек: айқын модель үшін минимум

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

Алдымен құрылғыны анықтау. Тикет карточкасында түсінікті идентификатор (инвентарлық нөмір немесе сериялы нөмір) және модельдік байланыс болуы керек: серия, базалық конфигурация (CPU, ОЗУ, диск), жеткізу жылы және орнатылу орны. Бұл әсіресе парк аралас болса маңызды: бір модельдің ескі және жаңа партиялары әртүрлі мінез көрсете алады.

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

Уақыт — есептің негізгі дереккөзі. Жауап беру уақыты мен шешу уақытын, сондай-ақ нақты жұмыс сағаттарын (hands-on) бөлек жинаңыз. Диагностикаға, түзетуге, пайдаланушымен коммуникацияға және эскалацияға кеткен уақытты бөлек белгілеу пайдалы. Тіпті қарапайым бөлініс ресурстар қай жерде жоғалып жатқанын көрсетеді.

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

Пайдаланушы простосы — ең даулы жайттардың бірі, бірақ оны ұқыпты тіркеуге болады. Инженерден қаржылық шығынды бағалауды талап етпеңіз. Тикетте жұмыс орнының қолжетімсіздік ұзақтығын және пайдаланушы ролін (мысалы, бэк-офис, оператор, дәрігер, бухгалтер) жазу жеткілікті. Кейін сіз топ үшін орташа сағаттық құнды немесе коэффициенттерді тағайындайсыз. Қысқа инциденттер үшін шекті қойыңыз: простой 15–30 минуттан асағанда ғана есептелсін.

Егер парктың бір бөлігі жергілікті өндірілген ПК-мен жаңартылса, жеткізу партиясы мен модель белгісін қосу пайдалы (мысалы, L200 немесе M200 сериясы). Сол кезде «бұрын/кейін» салыстыру нақты деректерге негізделеді: қандай инциденттер кетті, қайсысы қалды және олар қаншаға шығады.

Қолдау сұрауларын модельге байлау

Есеп адал болу үшін әр өтінішті жай ғана «пайдаланушы ПК» деп емес, нақты модель мен конфигурацияға байлау керек. Әйтпесе "GSE L200", "L200-8/256", "жаңа ПК бухгалтер" сияқты дубльдер шығады.

Модельдер каталогын құрып, барлық «жергілікті» атауларды синоним ретінде қосыңыз. Практикалық тәсіл: модельдер справочнигін (мысалы, GSE L200 Series, M200 Series, S200 Series) және типтік конфигурациялар справочнигін бөлек жүргізіңіз (ОЗУ, диск, ОС, критикалық периферия). Тикетте «модель + конфигурация» жұбы сақталсын, еркін мәтін емес.

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

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

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

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

Инциденттерді түрі мен қиындық деңгейі бойынша классификациялау

Инциденттерді бірдей жазу керек, әйтпесе бір инженер «ПК жұмыс істемейді» деп жазса, екіншісі «драйверді қайта орнату» деп жазады — салыстыру мүмкін болмай қалады.

Алдымен бірінші линияны жабатын қарапайым түрлер жиынтығын келісіңіз:

• Қарапайым ПО (баптаулар, жаңартулар, типтік бағдарлама орнату)
• Күрделі ПО (бизнес-бағдарламалар қателері, конфликтілер, терең диагностика)
• Периферия (принтерлер, сканерлер, гарнитуралар, док-станциялар, мониторлар)
• Железо (диск, жад, қызып кету, тұрақсыздық, компоненттерді ауыстыру)
• Доступтар (есептік жазбалар, құқықтар, MFA, блоктаулар, домен)

Кейін қиындық деңгейін лауазым бойынша емес, нақты еңбек шығындары бойынша қойыңыз. Үш деңгей ыңғайлы:

• L1 — нұсқаулықпен шешіледі және аз уақыт алады (әдетте 15–20 минутқа дейін)
• L2 — диагностика, бірнеше қадам, қашықтан қосылу немесе выезд қажет (шамамен 20–60 минут)
• L3 — терең талдау, профильдік маман қатысуы, вендормен келісім немесе тесттер (көбіне 1 сағаттан асады)

Қайталаулар мен эскалацияларды бөлек белгілеңіз. Қайталама — бірдей симптом сол құрылғыда немесе пайдаланушыда қысқа мерзімде қайталанған жағдай (мысалы, 7–14 күн). Эскалация — өтініш келесі деңгейге кеткенде (L1 → L2/L3) немесе басқа бөлімге бағытталған кезде.

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

Мысал: «ноутбукте Wi‑Fi жоғалуы» бастапқыда «периферия/железо» L1-ге түседі, бірақ драйвер жаңартпасынан кейін проблема қайталанса — қайталама болып тіркеліп, L2-ге эскалирленеді. Осылай белгілі бір модель немесе партия қымбат өтініштер беретінін көруге болады.

Есептеу моделі: өтініш құны неге тең

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

Ыңғайлы формула барлық техника түрлері үшін:

Қолдау сұрауының құны = еңбек шығындары + материалдар + простой (қолданылса).

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

Материалдарға расходник пен запчастьтар, жеткізу немесе выезд кіреді, егер олар бөлек төленсе.

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

Сағаттық ставка және шатаспаудың жолдары

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

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

Нормалау және уақыт туралы нашар деректер

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

Егер тикеттерде уақыт өрістері жоқ немесе деректер нашар болса, практикалық қадамдардан бастаңыз: типтік жұмыстарға нормалар енгізіңіз («пайдалану образын қайта орнату», «диск ауыстыру»), айына 10–20 таңдамалы тикетті хронометраждаңыз, минималды талап қойыңыз (басталу уақыты, аяқталу уақыты, орындаушы) және қай жерде уақыт «бағалау» екенін белгілеңіз. Дәлдікті біртіндеп арттырыңыз.

Практикалық қадамдар бойынша әдістеме

Бір анық кезеңді алыңыз (мысалы, 8–12 апта) және не салыстыратыныңызды алдын ала шешіңіз. Көбінесе «бұрын» және «кейін» жаңарту үшін бірдей бөлімдер мен ұқсас тапсырмалар салыстырылады.

1) Деректерді сенімді ету

Алдымен «шуды» алып тастаңыз, әйтпесе қорытынды даулы болады.

Таңдалған кезеңнен service desk-тан тикеттерді шығарып, деректерді тазалаңыз: дубльдер, тесттік өтініштер, бос өрістер, орындаушысы жоқ өтініштер. Содан кейін тикеттерді инвентарьға ID бойынша байлаңыз (asset tag, сериялы нөмір, hostname). Егер тикетте ID жоқ болса, ереже қойыңыз: ондай өтініштер «байланыспаған» санатына түссін.

Байлау кейін қамтуды тексеріңіз: тикеттердің қандай пайызы нақты модельдерге байланған. Егер 70–80%-дан төмен болса, алдымен өрістерді толтыру тәртібін жақсарту маңызды.

2) Белгілеу, есептеу және салыстыру жинау

Содан кейін бір логика бойынша барлық проблемаларды бірдей санау керек.

Инцидент түрін және қиындық деңгейін ережелерге сай қойыңыз (мысалы: «ПО», «периферия», «желі», «железо» және қиындық 1–3), даулы жағдайларды комментарийде белгілеңіз.

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

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

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

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

Ұйымда парктың бір бөлігі жаңартылды: бухгалтерия мен аналитиктерге жаңа ПК (модель B), ал аймақтарда ескі модель A қалдырылды. Қайшы конфигурациялар мен түрлі драйвер/BIOS нұсқалары пайда болды. Қолдау: «төмендеу» шағымдары азайды, бірақ «жүктелмейді» және «құрылғы көрмейді» сияқты үйлесімділік мәселелері көбейді.

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

Мини-кесте: модель A vs модель B

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

Шешім мысалы бойынша қадамдар:

• Егер модель A-да өнімділік мәселелері мен қымбат выездтар көп болса, тұрақты жөндеуден гөрі жоспарлы ауыстыру тиімдірек.
• Егер модель B-да негізгі мәселе үйлесімділік болса, алдымен ПО мен баптауға тәртіп енгізу керек, әйтпесе келесі сатып алуда мәселе қайталанады.
• Егер 100 ПК бойынша құн айырмасы 2–3 ай бойы тұрақты болса, оны жылдық әсерге айналдырып, жаңарту бюджетін салыстырыңыз.
• Паркта модельдер тым көп болса, қолдау шығындары өседі. Мақсат — 1–2 серия мен бір конфигурацияны стандартизациялау.

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

Есептеудегі жиі қателер мен тұзақтар

Service desk-тан алынатын деректер көбіне есеп үшін, талдау үшін емес жиналады. Сондықтан есеп әдемі сандарға айналып, нақты шешімге көмектеспеуі мүмкін.

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

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

Үшінші қате — әртүрлі кезеңдерді салыстыру. Маусымдықтық, жаппай ПО жаңартулары, қауіпсіздік саясатының өзгеруі немесе жаңа қосымшалар инцидент ағынын өзгертеді. «Наурыз пен қыркүйек» салыстыруы тура нәтиже бермей қалуы мүмкін.

Төртінші тұзақ — простайды асыра бағалау. Көбіне максималды мәндерді қояды да орташа жалақыға көбейтеді, бірақ нақты қанша уақыт пайдаланушы жұмыс істей алмағанын және алмастыру болғанын тексермейді.

Тағы бір жиі қателік — модельдерді конфигурация бойынша бөлмеу. Бір серияда түрлі SSD, ОЗУ немесе Wi‑Fi модульдер болуы мүмкін, және мәселелер әртүрлі болады.

Қорытынды тексеріс алдында қысқа тізім:

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

Егер «модель A» көп инцидент берсе, алдымен ол модельде басқа драйверлер немесе басқа партия компоненттері тұрған жоқ па тексеріңіз. Көбінесе себеп сол жерде болады.

Есепті көрсетуден бұрын қысқа чек-лист

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

Тикет карточкаларының толықтығын тексеріңіз

Әр өтініште негізгі өрістер толтырылған болуы керек, әйтпесе есеп жорамалына айналады. Түрлі бөлімдер мен мерзімдерден 20–30 тикетті таңдаңыз және тексеріңіз:

• Құрылғы моделі мен инцидент түрі көрсетілген ме (мүмкін болса «прочее/другое» пайдаланбау).
• Уақыт өрістері жоқ тикеттер үлесі алдын ала қабылданған шектен (мысалы 5–10%) аспағанын қадағалаңыз.
• Қайталанатын өтініштер белгіленген және бастапқыдан айқын ажыратылған.
• Тикетте жұмыс істеген кім екені түсінікті (1-я линия, 2-я линия, выезд) және сипаттамамен сай болуы қажет.
• Уақытты дөңгелектеу ережелері бірдей қолданылған (мысалы 15 минутқа дейін).

Содан кейін 3–5 бірдей инцидент бойынша уақыттарды салыстырыңыз. Егер өте үлкен айырмашылық болса, себебі әртүрлі детализация немесе кейбір әрекеттер тикеттен тыс орындалған болуы мүмкін.

Есеп «нені істеу керек» сұрағына жауап беруі керек

Итог кестелерде толық құн бойынша көшбасшы 3 модель және көшбасшы 3 инцидент түрі көрінуі тиіс — көбінесе олар негізгі әсер береді.

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

Ауыстыру немесе жөндеуді негіздеу және одан кейін не істеу керек

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

Әр проблемалық құрылғы класы үшін (мысалы, «модель X, жасы 4+ жыл»):

• Мәселе: қай инцидент түрі қайталанып жатыр және пайдаланушыларға қалай әсер етеді.
• Себеп: нақты не бұзылады немесе не баяулатуда (темір, ОС, драйверлар, тозу, үйлесімсіздік).
• Шығын: бір өтініштің орташа құны және айлық/тоқсаптық болжам.
• Варианттар: жөндеу немесе ауыстыру, сондай-ақ стандартизация немесе дооснащение әсері.
• Окупаемость: қанша айда шығындар өтініштер мен простайды азайту есебінен өтеледі.

«Жөндеу vs ауыстыру» ғана емес, аралас нұсқаларды да салыстырыңыз: ПК-ны стандартқа келтіру (бір образ, бір драйвер топтамасы), парктың бір бөлігін ауыстыру, тек SSD немесе жад қоятын дооснащение, немесе құрылғы түрін өзгерту (ПК-дан моноблокқа). Сатып алу және қаржы үшін маңызды екі аргумент: өтініштердің болжамды саны (яғни шығындардың болжамы) және простой тәуекелі.

Мысал: ескі модель бухгалтерияда айына 18 өтініш береді, орташа құны 12 000 тг, қосымша 2 рет 3 сағаттық простой бар. Жөндеу уақытша 1–2 ай ғана үнем бере алады, себебі қайталану жиілігі төмендемейді. 20 жұмыс орнын ауыстыру және стандартизациялау өтініштерді жартылай азайтады және 6–8 айда өзін ақтайды.

Әрі қарай қысқа циклмен әрекет етіңіз:

• ең көп өтініш беретін 20–50 жұмыс орнын пилот ретінде таңдаңыз
• шешімді (ауыстыру, дооснащение немесе стандартизация) енгізіп, өзгерістерді тіркеңіз
• 1–2 айдан кейін сол ережелер бойынша қолдау құнын қайта есептеңіз
• әсер расталғаннан кейін ғана бүкіл паркты кеңейтіңіз

Егер жаңарту жоспарлап отырсаңыз және қолдауды төмендетуді мақсат етсеңіз, алдын ала модельдер мен конфигурацияны стандартизациялау орынды. Қазақстанда үшін жиі GSE.kz сериялары қарастырылады (мысалы, настольные ПК L200 Series және моноблоки M200 Series), ал инфрақұрылым үшін — серверлер S200 Series және жүйелік интеграция қызметтері, осылайша жеткізу, енгізу және қолдау жауапкершілігі бастапқыда анықталады.