Тәуелсіз жүйелік интегратор бір вендордан қашан тиімді?

Тәуелсіз интегратор мен бір вендордың арасындағы таңдау коммерциялық ұсыныстағы логотип санына байланысты емес. Microsoft, Oracle және SAP байланысы үшін үйлесімділікті, лицензиялауды және қолдауды жазбаша бір жауапкершілік үлгісіне біріктіретін мердігер тиімді. Интегратор әр өндірушімен кәсіби түрде келіспей, жүйелер түйіскен жерге жауап бере алса, тәуелсіздік пайда әкеледі. Ондай мүмкіндік болмаса, ол хат алмасудың тағы бір қабатына айналады.

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

Жауапкершілік бекітілсе, тәуелсіздік көмектеседі

Бизнес-процесс бірнеше өндірушінің өнімі арқылы өтіп, бүкіл тізбекке ешқайсысы иелік етпесе, тәуелсіз жүйелік интегратор бір вендордан тиімді. Әдеттегі мысалда пайдаланушы Microsoft қызметтері арқылы кіреді, операция SAP жүйесінде жасалады, деректер Oracle жүйесіне түседі, ал есеп кеңсе қолданбасына қайтады. Толық операция бұзылып тұрса да, әр компонент қалыпты жұмыс істеуі мүмкін.

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

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

Әр маңызды процесс бойынша жауапкершілікті бір сөйлеммен сипаттауды сұраңыз: «Интегратор тапсырыстың есептік жазбадан өткізбе мен есепке дейін жүруін қалпына келтіреді, оған Microsoft, Oracle және SAP өтінімдерін үйлестіру де кіреді». Содан кейін ерекшеліктер тізімін талап етіңіз. Егер сол тізім процесті өнімдер бойынша қайта бөлсе, алдыңызда диспетчер қызметін атқаратын қайта сатушы тұр.

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

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

Үйлесімділікті нақты нұсқамен дәлелдеу қажет

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

SAP Product Availability Matrix құжатында шығарылымды қолдау мерзімін, жаңарту жолдарын және қолдау көрсетілетін платформаларды жариялайды. Бұл бастапқы нүкте, бірақ дайын жоба емес. Microsoft тұрақты және заманауи қызмет көрсету үлгісіндегі өнімдер үшін бөлек өмірлік цикл саясаттарын жүргізеді. Oracle Licensing Information User Manual дерекқор редакциялары бойынша функциялар, опциялар және пакеттер қолжетімділігін көрсетеді. Бұл құжаттар әртүрлі сұраққа жауап береді, сондықтан біреуіндегі жасыл белгі бүкіл байланысты растамайды.

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

PROCESS;SAP_RELEASE;DB_EDITION;DB_PATCH;OS_BUILD;DRIVER;AUTH;OWNER;EVIDENCE_DATE
order_posting;S4_RELEASE;ORACLE_EDITION;RU_LEVEL;WINDOWS_BUILD;CLIENT_VERSION;AD_METHOD;team_name;YYYY-MM-DD

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

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

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

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

Лицензиялар қол жеткізу ағыны бойынша есептеледі

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

Microsoft multiplexing жөніндегі нұсқаулығында қосылыстарды біріктіру немесе автоматтандыру қажетті лицензия санын азайтпайтынын тікелей жазады. Қолданба көптеген пайдаланушының сұрауын жинап, сервер өніміне бір техникалық есептік жазба арқылы жүгінсе, сол бір жазба бір ғана қол жеткізу бар екенін дәлелдемейді. Server/CAL үлгісінде функциялар мен деректерді кім немесе қандай құрылғы жанама алатынын тексеру қажет. Ядро бойынша лицензиялауда физикалық және виртуалды топологияны, лицензияны ауыстырып тағайындау құқықтарын және таңдалған бағдарламаның ережелерін қарау керек.

Oracle ортасында редакциялар, опциялар және management packs бөлек тәуекел тудырады. Орнатылған бағдарламалық жасақтамада функцияның болуы оны қолданыстағы шарт бойынша пайдалануға құқық бермейді. Мониторинг құралы бөлек лицензияланатын пакетке жататын деректерге немесе мүмкіндіктерге жүгіне алады. Сондықтан интегратор нақты қосылған функцияларды шартпен және өзекті Licensing Information User Manual құжатымен салыстыруы тиіс. Архитектордың ауызша жауабы аудит үшін жеткіліксіз.

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

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

1. Операцияны бастаушы, оған қызметкер, құрылғы, сервис немесе робот кіреді.
2. Қосылыстарды біріктіретін, деректерді кэштейтін немесе түрлендіретін аралық тораптар.
3. Операция соңында жүгінетін өнім мен функция.
4. Өнім жұмыс істейтін есептеу ортасы, оның ішінде резервтік және сынақ даналары.
5. Лицензиялық өлшем және есеп негізделген құжат.

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

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

Бір шарт қолдау шекарасын жоймайды

Бір шарт нәтиженің бір иесін белгілегенде ғана пайдалы. Бас мердігерлік Microsoft, Oracle және SAP компанияларын оқиғаны бірге талдауға мәжбүрлемейді. Ол тапсырыс берушіге келісілген сервис деңгейін талап ететін бір тарап қана береді. Нәтиже сол тарап қатені қайталауға, дәлел жинауға және қызмет қалпына келгенше өтінімдерді жүргізуге міндетті ме деген сұраққа байланысты.

Шартта сервисті қалпына келтіру мен бастапқы себепті жоюды ажырату керек. Өндіруші ақауды талдап жатқанда, интегратор драйверді кері қайтарып немесе резервтік торапқа ауысып, дерек алмасуды қалпына келтіре алады. Егер SLA уақыты өтінім вендорға берілген сәтте тоқтаса, тапсырыс беруші пошта жәшігін сатып алған. Уақыт келісілген бизнес-процесс қалпына келгенде немесе нақты аталған басқа күйге жеткенде тоқтауы тиіс.

Шекара қатені қайталап шығару туралы дауда анық көрінеді. SAP қолдау көрсетілетін дерекқор нұсқасында тексеруді сұрауы мүмкін, Oracle бөгде драйверді алып тастауды талап етеді, ал Microsoft операциялық жүйе компонентін жаңартуды ұсынады. Әр талап жеке өнім ішінде орынды, бірақ бәрі қосылып тұйық шеңбер жасайды. Интегратор оны басқарылатын стенд арқылы бұзады: бастапқы қатені тіркейді, әр жолы бір компонентті ғана өзгертеді, нәтижелерді сақтайды және ақау жоғалатын ең аз комбинацияны табады.

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

Үлгіні шарттық жаттығумен тексеру оңай. Үміткерге мына сценарийді беріңіз: операциялық жүйе жаңарғаннан кейін SAP жүйесінен Oracle жүйесіне пакеттік жүктеу тұрып қалады, интерактивті операциялар жұмыс істейді, ал қолданба жеткізушісі қатені қайталай алмайды. Алғашқы әрекеттерді, әр өндірушімен байланыс иесін, SLA уақытын тоқтататын шартты және кері қайтаруға рұқсат беретін адамды атауды сұраңыз. Нақты жауап жұмыс істейтін қызметті көрсетеді. «Барлық тарапты үйлестіреміз» деген жалпы сөз болашақ хаттар кезегін көрсетеді.

Өзгеріс құны енгізу құнынан маңызды

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

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

Қарапайым формула көмектеседі:

CHANGE_COST = LICENSE_DELTA + IMPLEMENTATION + RETEST + DOWNTIME + SUPPORT_DELTA + EXIT_WORK

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

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

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

Архитектуралық дауға тәуелсіз шешім қажет

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

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

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

Даулы тармақтарға қысқа шешім жазбасы пайдалы:

DECISION;CONSTRAINT;OPTIONS;TEST;LICENSE_EFFECT;SUPPORT_EFFECT;REVERSAL_TRIGGER;OWNER
database_driver;support_matrix;v1|v2;batch_and_failover;reviewed;case_confirmed;error_rate_limit;architecture_owner

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

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

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

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

Тәуелділік шығу құнымен өлшенеді

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

Бес активті тексеріңіз: деректер схемасы, интерфейстер сипаттамасы, ортаны құру сценарийлері, бизнес-процесс сынақтары және архитектуралық шешімдер тарихы. Тапсырыс беруші оларды өңделетін түрде алып, жаңа командаға беруге құқылы болуы керек. Егер мердігердің ішкі білім қорынан алынған PDF арқылы стенд құрып, дерек алмасуды қайталау мүмкін болмаса, мұндай экспорт жарамайды.

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

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

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

Жергілікті инфрақұрылым өлшемдерді өзгертеді

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

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

GSE Қазақстанда компьютерлер, жұмыс станциялары, моноблоктар және S200 серверлерін өндіреді, сондай-ақ Microsoft, Oracle, SAP және басқа шешімдерді жүйелік біріктіреді. Көпвендорлық жобада бір команда жабдық конфигурациясын, жеткізуді, енгізуді және тәулік бойы қолдауды бүкіл елдік сервис желісімен байланыстыра алады, бірақ бұл шекараларды сипаттама мен SLA құжатында бәрібір бекіту қажет.

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

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

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

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

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

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

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

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