В това интервю за Help Net Security Гилерме Жовентино, главен оперативен директор на MIGNOW, обяснява защо някои големи компании планират да останат на ECC след крайния срок през 2027 г. и да плащат на SAP за удължена поддръжка до 2030 г. Интервюто разглежда какво може да струва този избор, защо страхът от прекъсване на работите спира проекти по-често от бюджета и какво включват първите деветдесет дни от поетапната миграция. То също така разглежда служителите, които притежават дългогодишни познания за старата система, и проект в Централна Америка, който е преминал през всички проверки за качество, но все пак е имал трудно пускане в реална експлоатация.
Това възниква най-често при клиентите ни с поетапно внедряване. Един от тях, голям глобален производител, ни посети неотдавна. Те следват официален корпоративен план за поетапно внедряване, който определя кои държави стартират в реална експлоатация и в какъв ред, и 2027 г. просто не е част от този разговор. Причината е елементарна: SAP ви продава допълнителни години поддръжка, ако сте готови да си платите, така че можете да останете там, където сте, до 2030 г. За големите компании таксата за допълнителна поддръжка е малка в сравнение с разходите за самия проект за миграция, и те предпочитат да защитят последователността на внедряването, вместо да съкращават всичко, за да спазят определена дата.
Искам да бъда внимателен относно това какво им е струвало това, защото все още не сме достигнали 2027 г. и не мисля, че днес някой може да посочи достоверна цифра. Това, което мога да ви кажа, е че отговорът зависи почти изцяло от това как компанията използва системата. Ако ERP системата носи иновации, пускане на нови продукти, нови бизнес модели, тогава всяка година забавяне има цена, дори тя никога да не се появи във фактура. Ако системата е основно финансов бек-офис, рискът наистина е нисък, защото тези процеси почти не се променят от една година до следващата. Това е променливата, която решава дали чакането ви струва нещо изобщо.
Въпреки това виждаме модел, който сочи в една посока. Компаниите, които се отнасят към SAP стратегически, вече са преминали. Тези, които са избрали да изчакат, почти без изключение са онези, които я използват като бек-офис. Така че, въпреки че финансовото въздействие не може да бъде напълно измерено през 2026 г. и ще стане видимо едва по-късно, ние сме убедени, че стратегическите потребители извличат реална полза от това, че са преминали първи. Те вече надграждат върху новата платформа, докато останалите все още планират прехода.
Единственото число, което е конкретно днес, е от страна на поддръжката. SAP таксува приблизително 2% над стандартната такса за поддръжка на корпоративно ниво за удължаване на поддръжката, а тази такса вече е процент от стойността на лиценза, плащан всяка година. За лиценз от един милион плащате около 22% годишно, така че удължението е реален разходен ред, но просто не е достатъчно голям сам по себе си, за да промени мнението на повечето хора. Ето защо ние определяме това като стратегическо решение с нашите клиенти, вместо да го оставяме да се превърне във въпрос за купуване на застраховка за краен срок.
Бюджетът рядко е истинската пречка, той обикновено е просто най-лесното нещо, което може да се каже на глас. Под повърхността по-честият двигател е страхът от прекъсване на работите и по-специално страхът, че миграцията ще прекъсне нещо, което бизнесът не може да си позволи да прекъсне. На практика този страх обикновено се фокусира върху шепа много конкретни моменти: дати за финансово приключване, пикови оперативни прозорци, вече задействани ангажименти за инвентар или логистика. Екипите се страхуват от деня, в който системата стартира в реална експлоатация и нещо се счупи в рамките на прозорец, който те не могат да отложат.
Недостигът на персонал също е реален, но той обикновено се появява по-късно, след като решението вече е взето и компанията осъзнае колко малко хора вътрешно все още разбират пълния обхват на персонализациите, натрупани през последните десет или двадесет години.
Страхът от прекъсване е най-трудният за решаване от трите, защото уверенията сами по себе си не го коригират. Това, което задвижва решението, са доказателствата: да видиш друга компания с подобен размер и сложност да преминава през това, без бизнесът да спре, и да имаш тестван план за конкретните оперативни прозорци, които са най-важни. Докато такова доказателство не съществува, нито един бизнес случай не може сам да запълни тази празнина. Ето къде нашият досегашен опит върши повече работа от всеки аргумент, който можем да изтъкнем.
Първите деветдесет дни не са самата миграция, те са това, което наричаме предпроектна фаза – фазата на настройка и проучване, и според нашия опит те решават как ще протече останалата част от проекта. При проект за актуализация прозорецът е още по-кратък, по-близо до първите тридесет дни, защото тези проекти се движат по-бързо.
Първата задача е трансфер на знания за самата методология: прекарване на клиента стъпка по стъпка през това как се извършва конверсията, от подготовката на средата до крайната доставка. Това може да звучи като процес сам по себе си, но е единичният най-голям фактор за успех, който имаме, защото той съгласува всеки заинтересован субект около една и съща последователност и предпазва проекта от спиране. Това е, което позволява на нашия изкуствен интелект да работи без прекъсвания, и оттук идва реалното ускорение: технологията осигурява скоростта, на която е способна, само когато процесът около нея не спира постоянно.
Оттам нататък работата е техническа и функционална подготовка: детайлно планиране на проекта, изграждане и конфигуриране на средите според определеното в предпроекта и изграждане на функционално разбиране за това какво е в обхвата. Това е и мястото, където се определя планът за тестване – кои процеси трябва да бъдат валидирани и кой ги одобрява, защото тестването е частта, която решава колко спокойно ще бъде пускането в реална експлоатация, и е твърде късно да се организира, след като конверсията вече се изпълнява. Това, което определя дали това ще се случи навреме, е почти винаги от страна на клиента – собственото му време и внимание, както и наличността на ресурси (хора, както и инфраструктура и достъп до системи), така че проектът да може да бъде изпълнен.
Ето защо прекарваме първите дни в работа по методологията. След като клиентът разбере как работи конверсията, той разбира защо предпроектът е важен и подготовката спира да се третира като допълнителен разход и започва да се разглежда като част от миграцията.
Честно казано, това се превръща в бъркотия по-често, отколкото се планира. Хората, които познават старата система най-добре, обикновено са тези, чиито знания са най-малко документирани, защото те живеят в главите им след години справяне с особеностите на системата и ръчно отстраняване на пропуските между финанси, логистика и отчитане.
Често срещан и показателен пример: някой, чиято работа с години е била ръчно да извлича данни от различни области в една електронна таблица, за да може ръководството да види едно консолидирано число – работа, която преди е отнемала дни. След миграцията същият този резултат отнема минути. Старата работа на този човек практически изчезва и дали това е победа или загуба зависи изцяло от това дали компанията е планирала това.
Компаниите, които се справят добре с това, идентифицират тези хора рано и им дават двойна роля за времетраенето на проекта – отчасти оперативно управление и отчасти институционална памет за екипа по миграцията, а след това целенасочено ги пренасочват към аналитична дейност с по-висока стойност, след като ръчната задача бъде автоматизирана. Тези, които не планират това, или губят този експертен опит поради текучество по средата на проекта, което води до забавяния, тъй като никой друг не може да обясни защо съществува дадена персонализация, или оставят човека на роля, която вече няма нужда да съществува, което сама по себе си е скрит разход.
Примерът, който ми идва наум, е компания за производство и дистрибуция в Централна Америка. Това е партньорство, което в крайна сметка завърши добре – те все още са с нас и в момента изпълняваме обновяване за тях, като на хартия първоначалният проект беше успешен: завършен, в реална експлоатация, с преминати всички проверки за качество в нашата методология. Все пак го определям като разочарование, защото пускането в реална експлоатация беше по-трудно, отколкото трябваше да бъде, а причините имаха много малко общо със самата технология и бяха изцяло свързани с това колко подготвена беше средата около проекта.
Накратко, средите не бяха оразмерени по начина, по който изисква конверсия с такъв размер, така че това, което трябваше да бъде едно пускане в експлоатация, се превърна в две. А екипът от страна на клиента беше малък и носеше проекта наред с ежедневните си задължения, така че покритието на тестовете в няколко оперативни области се оказа по-слабо, отколкото някой от нас осъзнаваше тогава. Проблемите, които видяхме през първите дни в реална експлоатация, бяха концентрирани почти изцяло там.
Това, което извличам като извод, е, че качеството на пускането в реална експлоатация се решава отдавна преди самата дата на стартиране и се определя от подготовката. Нашият изкуствен интелект прави конверсията предвидима, а нашата методология прави всичко около нея предвидимо, като гладкото пускане в експлоатация изисква и двете. Една конверсия изглежда гладка само когато средите са готови, когато тестването покрива процесите, на които разчита бизнесът, и когато резултатите от това тестване са записани по начин, който носи полезна информация. Когато клиентът разполага с техническа дълбочина и ресурс да управлява това сам, пускането в експлоатация протича спокойно, обикновено с един или два сигнала за проблеми в първите часове. Когато не разполагат, това е недостиг на капацитет и нашата работа е да го забележим рано и да го затворим, вместо да приемаме, че той ще се покрие от само себе си. Точно това направихме тук, поради което взаимоотношенията се запазиха и затова те се върнаха при нас за обновяването – и затова сега прекарваме реално време в началото на всеки ангажимент в подготовка и включваме наши собствени хора във фазата на тестване.
Организациите трябва да търсят решение, което автоматизира голяма част от усилията за тестване при конверсия. Идеята е автоматично да се генерира и изпълнява тестовото покритие и да се даде и на двете страни реална видимост върху това какво е валидирано, така че организация, която не разполага с дълбок технически екип, да не е тази, която носи този риск. За компании в такова положение това премахва най-голямата променлива при миграция и я прави далеч по-предвидима.