Open source-қа көшу TCO: адал есептеу шаблоны

Неліктен көшу алдында TCO есептеу керек

Тек лицензия бағасын есептеу — әдетте қателік. Лицензиялар бюджетте көрініп тұрады, бірақ негізгі шығындар көбіне басқа нәрселерге кетеді: команда уақыты, простои, қолдау, доработкалар, инфрақұрылым және тәуекелдер. Сондықтан open source-қа көшу TCO-сын алдын ала бағалау керек — сонда шешім қағаз жүзінде "арзан" емес, эксплуатацияда тиімді және тыныш болады.

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

Көбінесе бір ғана өнім емес, өзара әсер ететін шешімдер жиынтығын салыстырады: сервер және жұмыс орындары ОЖ, офис және пошта, СУБД мен қолданбалы сервистер, виртуализация және басқару, резервтеу және мониторинг.

Есептеу горизонын алдын ала таңдаған жөн. Практикалық минимум — 3 жыл: эксплуатация, жаңарту және қолдаудың шығындары көріне бастайды. Инфрақұрылым үшін 5 жыл жиі ақталады, себебі амортизация ұзақ және әсер бір-екі тоқсанға кешігіп көрінеді.

Егер шығындардың бір бөлігін жабдық пен жергілікті қолдайтын сервистер қалыптастырса, TCO IT мен қаржыны бір суретке жинауға көмектеседі. Серверлерді немесе жұмыс станцияларын жаңарту кезінде тек сатып алу құнын ғана емес, қызметтің қолжетімділігін, жеткізу мерзімін, гарантиялық қолдауды және сатып алу кезінде қойылатын жергілікті талаптарды ескеріңіз. Қазақстанда бұл әсіресе маңызды: мысалы, GSE.kz (gse.kz) Қазақстанда компьютерлер мен серверлер шығарады және жүйелік интегратор ретінде қолдау мен инфрақұрылымдық міндеттерді өз мойнына алады.

Есептеу шекаралары мен болжамдар

TCO адал болсын десеңіз, алдымен шекараны келісіңіз. Әйтпесе есеп дау-дамайға айналады: біреу барлық тәуекелді қосады, біреу жарты шығынды "ұмытып" қояды.

Жобаны қарапайым тілмен сипаттаңыз: қандай жүйелер көшіреді, қанша пайдаланушы қамтылады, қай жерде жұмыс істейді (офис, филиал, дата-орталық), қандай қауіпсіздік пен қолжетімділік талаптары бар. Мысалы, «300 офис пайдаланушысы және бухгалтерия мен құжат айналымы үшін 40 серверлік VM» — бір контур, ал аналитикалық платформа мен тест стендтері — басқа контур болуы мүмкін.

Сосын нақты қандай құрамдар есептелетінін бекітіңіз: қандай орта(лар) (prod/test/dev), пайдаланушылар категориясы (қалыпты, әкімшілер, мердігерлер), интеграциялар (AD, пошта, бэкап, мониторинг), қажетті SLA және жұмыс терезелері, сондай-ақ горизонт (әдетте 3–5 жыл).

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

Есеп бірліктерін таңдаңыз және бәрінде бірдей пайдаланыңыз: пайдаланушы, сервер, VM, CPU ядросы, стойка, ТБ. Open source және коммерциялық нұсқалар бірдей бірліктермен есептелуі маңызды.

Және соңғысы — болжамдар. Жүктеме өсуі (мысалы, жылына +15%), инфляция мен курс, жобаның мерзімдері, қолдау режимі (5x8 немесе 24/7) сияқты параметрлерді бекітіңіз. Егер интегратор мен сервис желісіне сүйенесіз бе — қолдауға не кіретінін: реакция уақыты, қалпына келтіру, жаңартулар, выездтер деп бөлек жазып қойыңыз.

Салыстыру базасы: лицензияларды ұзартудың қанша тұратынын есептеңіз

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

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

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

Бөлек жолда қолдауды ашыңыз: вендордан не, серіктестен не аласыз. Жолдар нақты болсын: қолдау деңгейі (сағат бойынша, 24/7 немесе 8/5), реакция уақыты мен жаңартулар, инцидент пен апдейт кезінде көмек. Қарапайым сұрақ: қолдауды алып тастасаңыз, ағымдағы нұсқада қауіпсіз жұмыс істей аласыз ба?

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

TCO құрамдас бөліктері: соңғы соманы неден жинайды

Нәтиже «еріп кетпеуі» үшін шығындарды корзиндерге бөліңіз. Ыңғайлы — екі ось: CAPEX (біржолғы инвестициялар) және OPEX (тұрақты шығындар), сондай-ақ тікелей және жанама шығындар.

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

Бірден разовые және тұрақты сомаларды ажыратыңыз. Негізгі ақша көбіне сатып алуда емес, 12–36 айдағы эксплуатацияда жиналады. Лицензиялардан үнемдеп, ал әкімшілендіру, оқыту және қолдау шығындарын бастапқы айларда көбейтуге болады.

Кестеге әдетте бес үлкен блок кіреді:

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

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

«Мелочтарды» есепке алудың ережесін де келісіңіз: ҚҚС (егер қолданылса), жеткізу, кеден шығындары, кеңейтілген гарантия, сервис келісімдері, қосалқы бөлшектер. Серверді ауыстырғанда залізо бағасы бірдей көрінгенімен, жеткізу, 3–5 жылдық гарантия және жөндеу шарттарын қосқанда нәтиже өзгереді. Қазақстанда жергілікті жеткізілім мен сервистің бар болуы простои тәуекелін төмендетеді — бұл TCO-ның жасырын бөлігін азайтады.

Кестенің астында бір жолда болжамдар болсын: есеп периоды, курс, инфляция, простаудың ставкасы. Бұл есепті даулардан қорғайды.

Қадамдық шаблон: кестені қалай толтыру керек

Бір кестемен бастаңыз және барлық сценарийлерге бірдей ережелер қолданыңыз: бір файл, бір горизонт (әдетте 3–5 жыл), бірдей шығын элементтері.

1. Қалай жұмыс істейтінін тіркеңіз: қолжетімділік, реакция уақыты, қызмет уақыт терезелері, ай сайынғы өтініш саны, команданың қолдауға жұмсайтын уақыты.

2. Мақсатты картаны сандық түрде сипаттаңыз: қанша сервер және қандай класс, қанша сақтау орны, қандай желі, қанша әкімші және қандай қолдау қажет. Күрделі архитектураны бірден әдемілеп салудың қажеті жоқ — сүйек құрылым жеткілікті.

3. Шығындарды жылдарға бөліңіз: біржолғы (көшіру, енгізу) — 0-ші жылға; тұрақты (қолдау, жазылымдар, электр) — жылдарға.

4. Резерв қосып, сенімділік шегін тексеріңіз: егер оқыту 2 айға созылса немесе инциденттер 20% көп болса не болады.

5. Сценарийлерді тек бірдей шарттарда салыстырыңыз: бірдей сервис деңгейі, бірдей көлем, бірдей болжамдар.

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

Серверлер мен есептеу: сатып алу, орналастыру, амортизация

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

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

Мощностьты есептегенде ағымдағы жүктеме + резерв беріңіз: пик, 12–24 айға өсім және түйіннің ақауына резерв (кластер болса).

Есепте сатып алу (сервер, желі, орнату), орналастыру (стойка, электр, салқындату немесе ЦОД қызметтері), эксплуатация (апгрейдтер, расходник, запас бөлшектер, гарантия ұзарту), амортизация (3–5 жыл) және тесттік/қосымша орта шығындарын қосыңыз.

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

Қысқаша мысал: 40 виртуалдық машинаны контейнер стекке ауыстыру кезінде CPU жеткілікті, бірақ RAM жетіспейді делік — нәтижесінде жадыны сатып алу, энергопайдалану өсуі және қосымша түйін қажет. Алдын ала есептемесеңіз, лицензия үнемішіңіз жоққа шығады.

Серверлерді жаңарту әдетте негізделеді, егер техниканың қызмет мерзімі 4–5 жылдан асса, гарантия жоқ болса немесе жаңа стек ескі жабдықта айтарлықтай төмен көрсеткіштер көрсетсе. Қазақстанда жергілікті өндірушімен жұмыс істеудің тағы бір артықшылығы — жеткізілім мен сервистің болжамдылығы.

Сақтау, бэкап және қалпына келтіру

Сақтауды TCO-да жиі төмен бағалайды, өйткені тек «пайдалы» деректерді есептейді. Шындығында сіз жұмыс файлдары, архив, журналдар, уақытша деректер, snapshot-тар және бэкаптар үшін төлейсіз, сонымен бірге өсімге резерв те қажет.

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

Сақтау түрлері және бағасы неліктен әртүрлі

Өнімді сақтау қымбат — себебі төмен латенттілік, жоғары IOPS, SSD жиі қолдану, контроллерлер мен желілік порттар көп қажет. Сыйымдылық сақтау арзан, бірақ дерекқорлар мен VM-лер дискіге күтіп отыра алмайды.

Кестеге көлемді классы бойынша бөліп, әр 1 ТБ-ға бағаны көрсетіңіз, соның ішінде полкалар, дисклер, контроллер және желі шығындарын қосыңыз.

Бэкаптар, DR және RPO/RTO құны

Бэкап тек бағдарламалық жасақтама емес. Сақтағыштар, бэкап терезесі (түнде немесе демалыста жүретін жүктеме), басқа алаңда көшірмелер сақтау және қалпына келтіру тесттері — бәрін есептеңіз. RPO/RTO қаншалықты төмен болса, көшірмелер, арналары және автоматтандыру көбірек қажет болады.

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

Мысал: 100 ТБ жұмыс дерегі және күнделікті көшірмелердің 60 күн ретенциясы болатын болса, бэкаптар көлемі «пайдалы» массивтің 2–4 есе өсуі оңай. Мұны салыстыру үшін адал база сол болады.

Қолдау және эксплуатация: адамдар, процестер, SLA

Қолдау көбінесе жалақыға «жасырылады» және тегін көрінеді. Шындығында бұл — меншік құнының ең қымбат бөліктерінің бірі: адамдар уақыты, дежурстволар, құралдар, регламент және қателіктердің құны.

Алдымен қолдау моделін таңдаңыз. "Тек ішкі команда" бақылауды береді, бірақ біліктілік пен дежурстволарды талап етеді. Мердігер кей бөлігін алып тастайды, бірақ ай сайын төлем мен SLA тәуелділігін қосады. Қоспа модель — көп жағдайда шынайы: ішкі команда рутинаны және архитектураны жабады, сыртқы серіктес — күрделі инциденттер мен 24/7.

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

SLA бюджетті ойлағаннан қатты өзгертеді. 8x5 пен 24x7 арасындағы айырмашылық — жай «тағы бір адам» емес, дежурстволар, эскалациялар мен қатты қалпына келтіру көрсеткіштері.

Эксплуатация құралдарын ұмытпаңыз. Тіпті ПО тегін болса да мониторинг, логтау, конфигурация басқару және бэкап үшін ресурстар және кейде лицензиялар қажет. Процестерге жұмыс та бөлек жолда көрсетілуі тиіс: регламенттер, runbook, сменді оқыту.

Практикалық мысал: егер екі жүйелік әкім платформаны "басқару арасында" ұстаса, миграция бастапқыда аптасына 10–15 сағат қосады. 24x7-ге өту — дежурство мен резервті сменалар керегін білдіреді. Егер 24x7 ішкі мүмкін болмаса, оны сыртқы сервиспен жабуға болады — бұл SLA құнын TCO-ға бөлек жолда қосу керек.

Оқыту және өзгерістерді басқару

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

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

Оқыту форматын араластыру тиімді. Сыртқы курс жалпы негіз береді. Ішкі тренингтер — нақты ережелеріңізге аудару. Алғашқы апталардағы тәлімгерлік қателіктер санын азайтады. Сертификация әр жерде міндетті емес, бірақ жоғары тәуекел немесе талаптар бар жерде пайдалы.

Өнімділіктің уақытша төмендеуін адал есептеңіз. 1–2 типтік рөлді алып (мысалы, бухгалтер мен оператор), олардың қазіргі тапсырмаларын санап, үйрену кезеңінде 10–20% өнімділік төмендеуі мүмкін деп есептеңіз, кейін біртіндеп қалпына келеді.

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

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

Простоилер мен тәуекелдер: резервті адал қосу

Тіпті open source лицензиялары нөлге тең болса да, TCO-де уақытша шығындар, қателіктер және доработкалар болады. Егер олар алдын ала есептелмесе, жоба қағазда арзан, өмірде қымбатқа түседі.

Простоилер жоспарлы (түн, демалыс), жартылай (барлығы жұмыс істейді, бірақ баяу) және авариялық (қате релиз, үйлесімсіздік, сақтаудың бұзылуы, роллбек) болуы мүмкін.

Бір сағат простаудың құнын қалай есептеу керек

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

Жұмыс формуласы: сағаттық шығын = (жоғалған кіріс немесе айыппұлдар) + (қызметкерлерге выплата) + (үдерістерді бұзудан келетін шығын) + (IT мен мердігерлердің қосымша жұмысы).

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

Уақыт пен бюджет бойынша резерв

Резерв интеграциялар бойынша доработкалар, күтпеген багтар, деректерді бірнеше рет көшіру сияқты болжауға қиын оқиғаларға арналған. Практикалық нұсқа: алғашқы толқындарға мерзім бойынша +15–30% және бюджеттің +10–25% қосу. Откатқа резерв бөлу: уақыт, лицензиялар параллельді жұмысқа және қосымша ресурстарға кетеді.

Заңдық және реттеуші тәуекелдердің де құны бар. Деректер талаптарын (қайда сақталады, кімге қолжетімді, журнал жүргізу), қолжетімділік талаптарын және қолдауды (кім түнде жауап береді) тексеріңіз. Егер талаптар қатал болса, алдын ала 24/7 кім қамтамасыз ететінін және сервер бөлшектерінің қаншаға тез жеткізілетінін шешіңіз.

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

Open source пен коммерциялық лицензияларды салыстыруда жиі кездесетін қателіктер

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

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

• әртүрлі мерзімдерді салыстыру (1 жыл лицензия vs бірнеше жыл меншік);
• IT жұмысын «тегін» санау (әкімшілер, инженерлер, қолдау, жоба жетекшісінің уақыты ақшаға айналуы қажет);
• үйлесімділік пен "мелочтар" дегенді ұмыту (интеграциялар, драйверлер, басып шығару, крипто, мониторинг, бэкап, есептер);
• лицензия үнеміне артық мән беріп, қолдауды төмен бағалау (open source = 0 шығын емес, әсіресе SLA және 24/7 талаптары болса);
• мақсатты сервис деңгейін бекітпеу (сонда дау цифрларға емес, "сапа" туралы болады).

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

Практикалық мысал: ұйым open source-қа көшіп, бір уақытта серверлерді жаңартса. Коммерциялық нұсқада тек лицензия ұзарту есептелсе, ал open source-та сервер мен СХД сатып алу қосылса, салыстыру әділетсіз болады. Железоны екі сценарийде де есептеу қажет, ал кестеде тек ПО-ға байланысты айырмашылықтарды өзгерту керек.

Есеп құрылымы мысалы және келесі қадамдар

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

Ыңғайлы құрылым, сізге өз цифрларыңызды қоюға болады:

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

«Open source тегін» емес, «сюрпризсіз жұмыс істеу қанша тұрады» деген сұрақты салыстырыңыз. Көп жағдайда шешуші фактор лицензия бағасы емес, SLA, критикалық қолданбалармен үйлесімділік, көшіру мерзімі және қателіктердің құны болады. Егер кейбір жұмыс орындарына міндетті бағдарламалар қажет болса, гибрид схема (бір бөлігі қалған күйінде, бір бөлігі көшіріледі) керек болуы мүмкін — бұл есепті едәуір өзгертеді.

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

Келесі қадамдар: әдетте шағын топта пилот өткізу, спецификацияларды нақтылау және сатып алу жоспарын жазу, содан кейін миграция кезеңіндегі қолдау жоспарын жасау. Көп тапсырманы жүйелік интеграторға тапсыру ыңғайлы: серверлер мен жұмыс станцияларын таңдау, инфрақұрылым жобалау, баптау және қолдау. Бір терезе жауапкершілігін (SLA + 24/7) маңызды санасаңыз, оны келісімшартта алдын ала нақтылатып, TCO-ға бөлек жолдармен енгізіңіз.