Решението за ERP започва преди демонстрацията на софтуера
Изборът на ERP може да промени ежедневната работа в цялата компания. Продажбите разчитат на данни за клиенти и ценообразуване; покупките — на търсенето и наличностите; производството — на спецификации (BOM), работни поръчки и капацитет; финансите — на проследими трансакции; а сервизът — на графици, части и фактуриране. Една ERP система свързва тези потоци, така че решението за един отдел може да засегне останалата част от бизнеса.
Ето защо процесът на избор на ERP не трябва да започва със списък с функции или стандартна презентация на доставчика. Той трябва да започне с целите на компанията, нейните текущи процеси и начина, по който тя иска да оперира в бъдеще. Ако заменяте по-стара ERP система, работата е още по-обхватна. Трябва да решите кои процеси и данни трябва да бъдат преместени, кои трябва да се променят, кои системи трябва да се свържат и кои стари практики трябва да бъдат преустановени.
Централният принцип е прост: разберете обхвата, преди да изберете системата или да се доверите на цена за внедряване. Това е най-важно, когато са включени много бизнес потоци или индивидуални разработки. Една кратка среща за продажби може да генерира предварителен бюджетен диапазон, но тя не може да разкрие всеки процес, данни, интеграция, миграция, нужди от тестване и обучение.
ERP експерти, пишещи в LinkedIn, описват същия модел от различни ъгли: избор, воден от демонстрации, неясни изисквания, непроучени наследени персонализации, неподготвени данни и слабо планиране на внедряването могат да оставят трудните решения за след подписването на договора. Това са наблюдения на практици, а не статистическо доказателство за провал на проекта. Те все пак са полезни сигнали за въпросите, които купувачът трябва да зададе рано. [1][2][3][4]
Първо решете от какъв вид промяна се нуждае бизнесът
Една компания не трябва да приема, че подмяната на ERP е единственият отговор. Една система може да се нуждае от надграждане (upgrade), повторно внедряване, селективна подмяна на свързани инструменти или по-широка ERP промяна. Правилният път зависи от бизнес проблема, техническото състояние на текущата среда и бъдещия оперативен модел.
| Опция | Какво означава | Въпроси, които да зададете |
| Запазване и подобряване | Запазване на текущата ERP система, като същевременно се подобряват процесите, данните, интеграциите или поддръжката. | Може ли текущата платформа да постигне целите на бизнеса с управляема промяна? |
| Надграждане (Upgrade) | Преминаване към поддържана версия или модел на внедряване, като се запазва голяма част от съществуващия дизайн. | Кои персонализирани функции и интеграции все още работят? Какво трябва да се промени при надграждането? |
| Повторно внедряване | Запазване на ERP продукта, но препроектиране на неговата конфигурация, процеси или данни. | Станала ли е системата трудна за използване поради нейния дизайн, а не поради самия продукт? |
| Подмяна | Избор на нова ERP система и преместване на договорените процеси и данни към нея. | Какви бизнес ограничения създава текущата среда и какво ще реши подмяната? |
Не сменяйте система само защото е стара или защото нов продукт изглежда по-модерен. Оценете дали текущата ERP система все още може да поддържа необходимата сигурност, отчитане, интеграции, мащаб и бизнес процеси. Консултантът по миграция в LinkedIn Сам Гупта прави това разграничение директно: възрастта сама по себе си не прави една ERP система остаряла; компанията трябва да проучи възможностите за поддръжка, персонализацията, ограниченията на интеграцията, мащаба и бъдещите нужди, преди да реши дали да остане, да надгради, да внедри повторно или да подмени. [3]
Решението трябва да включва и това, което няма да бъде променяно. Ако компанията има процес, който работи добре и създава реална клиентска или оперативна стойност, може би си струва да бъде запазен. Ако същият процес съществува само защото старата система не е могла да поддържа по-добър метод, копирането му в нова ERP система може да пренесе стария проблем напред.
Картографирайте реалния бизнес, преди да сравнявате софтуер
Един ERP проект се нуждае от ясна картина за това как се случва работата днес. Картата на процесите трябва да показва тригера, участващите хора и системи, необходимите данни, одобренията, предаването на задачи, изключенията и крайния резултат.
Например, производственият софтуер трябва да бъде оценен в целия поток: поръчка от клиент или прогноза; производство по поръчка (MTO), производство за склад (MTS) или хибридно производство; спецификация на материалите (BOM); планиране на материалите; изпълнение в работни центрове; записи за консумация, качество и продукция; готова продукция; доставка и финанси.
Други бизнеси трябва да картографират своите собствени потоци от край до край, като например от потенциален клиент до плащане (lead-to-cash), от заявка до плащане (procure-to-pay), от услуга до фактура, от проект до марж или от наемане до пенсиониране. Целта е да се покаже къде информацията пресича отделите и къде работата спира, повтаря се или зависи от електронна таблица.
Включете служителите, които извършват работата всеки ден. Процес, описан само от мениджъри, може да пропусне заобиколни решения, които поддържат операцията. Крайният потребител може да обясни защо дадено поле понякога е празно, защо поръчката е разделена, защо покупката е ускорена или защо клиент получава специално одобрение. Тези подробности могат да повлияят на дизайна на системата, миграцията на данни и оценките на проекта.
Един полезен семинар за процеси задава въпросите:
- Какво стартира процеса и какво трябва да е изпълнено, преди той да може да започне?
- Кой изпълнява всяка стъпка и кой може да я одобри или промени?
- Какви данни трябва да бъдат създадени, проверени или споделени?
- Коя ERP система, електронна таблица, машина, портал или друг инструмент е включен?
- Къде работата чака, повтаря се или се нуждае от ръчна корекция?
- Какво се случва, когато нормалният път се провали?
- Кои клиентски, законови, правила за безопасност или финансови правила се прилагат и как ще се измерва успехът?
Подходът на SIX към анализа на процесите използва този вид проучване преди конфигурацията. Публикуваните насоки за трансформация на SIX казват да се прегледат както формалните стъпки, така и неформалните заобиколни решения, да се картографира текущото състояние и след това да се проектира бъдещо състояние, което премахва ненужната работа, вместо да автоматизира всяко старо действие. [6]
Дефинирайте изисквания, които са свързани с бизнес резултатите
Картите на процесите показват как се движи работата. Изискванията описват какво трябва да позволи новата система. Доброто изискване е достатъчно специфично, за да бъде тествано, и е свързано с бизнес резултат, контрол, задължение или риск.
Например, „системата трябва да има производствен модул“ е твърде общо, за да насочи избора. По-силно изискване би било: „Когато потвърдена клиентска поръчка създава производствено изискване, плановикът трябва да може да види търсенето по BOM, наличните наличности, входящите поръчки за покупка и планираната работа, преди да освободи работната поръчка.“ Това изискване може да бъде демонстрирано и тествано.
Групирайте изискванията по важност и тип:
| Група изисквания | Какво обхваща | Пример |
| Задължителни (Must have) | Необходими за работата на бизнеса, спазване на правило или контрол на голям риск. | Проследяване на готов продукт обратно до неговата партида материали. |
| Препоръчителни (Should have) | Важни, но може да съществува безопасен временен метод. | Осигуряване на автоматизирано известие при промяна в наличността на материалите. |
| Възможни (Could have) | Полезно подобрение, което може да бъде планирано за по-късен етап. | Добавяне на ново табло за управление след стабилизиране на основния поток. |
| Извън обхват | Изрично изключени от първоначалния проект. | Подмяна на специализиран инструмент за проектиране, който не е част от ERP промяната. |
Присвоете собственик на всяко изискване. Собственикът на процеса трябва да потвърди бизнес нуждата; екипът на проекта трябва да запише как системата я удовлетворява; а ръководството трябва да одобри скъпи промени или приети пропуски. Това предотвратява превръщането на списъка с функции в колекция от некласирани желания.
Изискванията трябва също да обхващат потребители, местоположения, очаквания за реакция, достъп, сигурност, история на одита, архивиране, отчитане, съхранение, интеграции и поддръжка. Включете отрано множество юридически лица, валути, складове, производствени обекти или езици.
Решете какво да стандартизирате, конфигурирате, интегрирате или персонализирате
Пропускът (gap) е разликата между бъдещия процес, от който се нуждае бизнесът, и стандартните възможности на ERP системата. Пропускът не е автоматично причина за писане на персонализиран софтуер. Първо определете дали стандартен процес, конфигурация, промяна на процеса или специализирана интеграция могат да го решат.
| Подход | Значение | Кога може да е подходящ |
| Приемане на стандарт | Използване на процес, който вече се поддържа от ERP системата. | Стандартният процес е надежден и отговаря на бизнес нуждите. |
| Конфигуриране | Използване на вградени настройки, роли, одобрения, полета или работни потоци. | Процесът се нуждае от корекция без нов програмен код. |
| Интегриране | Свързване на ERP системата с друго приложение, машина или услуга. | Специализирана система трябва да остане в употреба, но нейните данни трябва да се свържат с ERP потоците. |
| Персонализиране | Добавяне или промяна на поведението на софтуера. | Доказано бизнес, регулаторно или клиентско изискване не може да бъде изпълнено добре по друг начин. |
| Промяна на процеса | Препроектиране на работата с цел подобряване или привеждане в съответствие с подходящ стандарт. | Старият метод добавя усилия, без да създава стойност или контрол. |
Персонализирането може да е правилно, когато даден процес защитава бизнес предимство, безопасност, законови задължения или ангажименти към клиенти. Всяка персонализирана функция се нуждае от собственик, бизнес обосновка, план за тестване и поддръжка. Тя може също да засегне свързани работни потоци, интеграции, надграждания, обучение и поддръжка.
Насоките на Microsoft за съответствие със стандарта (fit-to-standard) препоръчват сравняване на текущите процеси със стандартните ERP процеси, документиране на пропуските и разглеждане на цената, сложността и въздействието на предложените персонализации преди вземане на решение. Те също така съветват да се картографира ефектът върху свързаните процеси, а не само върху променяния процес. [7] Практическият урок не е „никога не персонализирайте“. Той е „направете така, че всяка персонализация да заслужи мястото си“.
Оценявайте продукта и партньора по внедряването заедно
Възможностите на софтуера са само част от решението. Подходът на партньора по внедряването, екипът, опитът и моделът на поддръжка могат да оформят резултата също толкова много. Оценете и двете като един избор за доставка.
Направете кратък списък със системи въз основа на задължителните изисквания, нуждите на индустрията, техническата среда, контрола на данните, модела на внедряване и вероятната обща цена. След това проиграйте едни и същи бизнес сценарии през всеки продукт. Доставчикът трябва да идентифицира дали всяка част е стандартна, конфигурирана, интегрирана или персонализирана.
Ерик Кимбърлинг, независим ERP консултант, който пише в LinkedIn, обяснява връзката ясно: „Изборът на ERP никога не трябва да се разглежда изолирано от внедряването.“ [1] Това е полезен тест за всеки процес на избор: оценявате ли как системата ще бъде доставена, мигрирана, тествана и възприета — а не само дали изглежда способна в презентация?
Изградете демонстрации около представителни списъци с артикули, клиентски структури, спецификации (BOM), ценови правила, обеми на трансакции и изключения. Защитете чувствителните производствени данни с подходящо споразумение и план за обработка на данни; демо данните трябва да показват реална сложност, без да излагат лична информация.
Поискайте от доставчиците да покажат:
- Нормална трансакция от началото до края.
- Често срещано изключение, като липсващи материали, частична доставка или отхвърлено одобрение.
- Как ролите и разрешенията контролират какво могат да правят различните потребители.
- Как се генерират отчети, одитни записи и проследимост.
- Как ERP системата работи със системите, които ще останат на място.
- Какво е включено в предложения продукт и лицензионен пакет.
- Какво изисква конфигурация, разработка, софтуер на трети страни или допълнителни услуги.
Идентифицирайте действителния екип на проекта: кой води проучването, дизайна на решението, миграцията, интеграциите и поддръжката след стартирането? Поискайте референции от компании с подобни процеси. Попитайте как се обработват поддръжката и бъдещите промени с разрастването на бизнеса.
Разглеждайте ранната оферта като приблизителна оценка, докато работата не бъде разбрана
Доставчикът може да предостави ранен бюджетен диапазон, за да помогне при вземането на решение дали да продължите, но той трябва да бъде обозначен като предварителен и обвързан с ясни предположения.
Фиксираната цена за внедряване изисква дефиниран обхват. Преди едно подробно предложение да се третира като надеждно, доставчикът трябва да разбере процесите, потребителите, обектите, юридическите лица, източниците на данни, обемите на трансакциите, интеграциите, изискванията за разработка, нуждите от тестване, обучението и плана за внедряване. Ако трябва да бъдат включени много потоци или индивидуални персонализации, това проучване става още по-важно.
Цена след кратък разговор за продажби може да предполага чисти данни, прости интеграции, налични потребители, малко персонализирана разработка или идентични процеси в обектите. Ако тези предположения са грешни, проектът може да се нуждае от повече бюджет, време или поръчки за промяна, или по-малък обхват.
Бъдете предпазливи към доставчик, който дава уверена фиксирана цена за внедряване, преди да проучи сложните работни потоци или нуждите от индивидуална разработка. Помолете доставчика да покаже как цената се отнася до документираните процеси и резултати. Едно отговорно предложение трябва да посочва:
- Включените процеси, модули, компании и местоположения.
- Необходимата конфигурация, интеграции и персонализирана разработка.
- Данните, които трябва да бъдат мигрирани, и отговорностите на клиента за данните.
- Броят и целта на тестовите цикли, обучителните сесии и пилотните дейности.
- Екипът по внедряването и очакваната наличност на служителите на клиента.
- Предположенията, изключенията, зависимостите и критериите за приемане.
- Процесът за преглед и ценообразуване на нови или променени изисквания.
- Уговорките за поддръжка и стабилизиране след стартирането.
Експертът в LinkedIn Дани Каплан специално подчертава проучването с реални потребители, прегледа на представителни данни и писмените изисквания, преди цената да се третира като окончателна. [2] Тази препоръка е особено подходяща, когато компанията има сложно ценообразуване за клиенти, голям обем трансакции, необичайни данни за продукти, производствени варианти или заобиколни решения, които никога не са били документирани.
Планирайте миграцията като програма за бизнеса и данните
Миграцията на ERP не е просто технически експорт и импорт. Старата и новата системи могат да използват различни дефиниции за клиенти, продукти, складове, сметки, мерни единици, одобрения или статус на трансакциите. Данните трябва да бъдат почистени, картографирани, тествани и съгласувани. Собствениците на бизнеса трябва да решат какво трябва да се премести и какво трябва да остане достъпно за справка.
Направете опис на текущата ERP система, електронни таблици, специализирани приложения, портали, машини и архиви. Запишете собственика на всеки набор от данни, потребителите, честотата на промяна и бизнес целта.
След това класифицирайте информацията:
| Тип данни | Примери | Въпрос за миграция |
| Мастър данни | Клиенти, доставчици, продукти, спецификации (BOM), служители, складове. | Актуални ли са, пълни ли са, правилно структурирани ли са и имат ли собственик? |
| Отворени трансакции | Поръчки за продажба, поръчки за покупка, складови наличности, отворени работни поръчки, неплатени фактури. | Какво трябва да бъде отворено и използваемо в първия ден на реална работа? |
| Необходима история | Фактури, записи за качество, сервизна история, записи за партиди, подробности за одит. | Какво трябва да бъде в новата система и какво може да остане в архив с възможност за търсене? |
| Стари или дублирани записи | Неактивни продукти, дублирани клиентски файлове, остарели доставчици. | Трябва ли те да бъдат почистени, архивирани, запазени по законова причина или изключени? |
Присвоете собственици на данни и правила за картографиране. Решете как да се справяте с дубликати, липсващи стойности, стари кодове и променени бизнес структури. Съгласувайте ключови записи след всеки тест за миграция, като финансови баланси или производствени наличности, активни спецификации (BOM) и отворена работа.
Не приемайте, че всички исторически данни трябва да бъдат заредени в реалната ERP система. Част от историята може да е необходима за ежедневно обслужване или гаранционна работа; други записи могат да бъдат достъпни чрез контролиран архив. Компанията трябва да избере въз основа на оперативни, финансови, одитни и законови нужди. Статията на Сам Гупта в LinkedIn за миграцията също подчертава собствеността върху мастър данните, почистването, историческите данни, съгласуването, репетициите и архивирането като области за планиране. [3]
Насоките на Microsoft за миграция по подобен начин призовават за договорен обхват и стратегия за данните, картографиране и трансформация на полета, тестване, валидиране и дефинирани роли. [8]
Наследени записи, преминаващи през валидиране на данни към свързани ERP процеси
Планирайте интеграциите, тестването и преминаването към новата система (cutover) отрано
Избройте всяка връзка, която трябва да продължи — счетоводство, ТРЗ, електронна търговия, портали, производствено оборудване, банкиране, складови устройства, транспорт или отчитане. Запишете обменяните данни, посоката, времето, собственика, обработката на откази и мониторинга. Тествайте реални обеми трансакции, необичайни данни и временни прекъсвания.
Тестването трябва да следва пълни бизнес потоци, а не да спира, когато е въведена поръчка или работна поръчка. Проверявайте данни, разрешения, отчети и финансови записи при нормални и трудни случаи.
Например, производствен сценарий може да тества поръчка, която изисква вариант на продукт, има недостиг на материали, нуждае се от поръчка за покупка, преминава през множество работни центрове, записва действителна консумация, преминава проверка на качеството и произвежда готова продукция за доставка и фактуриране. Сценарий за обслужване на място може да тества промяна на резервация, консумация на части от техник, одобрение от клиент и създаване на фактура.
Планирайте преминаването към новата система (cutover) като бизнес събитие. Дефинирайте кой „замразява“ старата система, кога се извличат окончателните данни, кои отворени трансакции се зареждат, кой проверява общите суми, кой предоставя достъп и как потребителите съобщават за спешни проблеми. Репетирайте преминаването в тестова среда с хората и инструментите, които се очаква да участват. Договорете решение за стартиране/нестартиране (go/no-go) и план за действие при извънредни ситуации преди старта.
Насоките на Microsoft за внедряване препоръчват тестван план за преминаване (cutover) с ясни задачи, собственици, проверка, одобрение и планиране на връщане назад. [9] Точната стратегия — еднократно стартиране или поетапно внедряване — трябва да зависи от системните зависимости, бизнес риска, сезонността, капацитета на персонала и способността за работа по време на прехода.
Подгответе хората за промяната
Една ERP система променя отговорностите и рутините. Потребителите могат да въвеждат данни по различен начин, да следват нови одобрения или да спрат да разчитат на електронни таблици. Без обяснение и практика те могат да създадат заобиколни решения извън системата.
Включете ключовите потребители отрано. Обучете всяка роля за реални задачи, като покажете как работата на потребителя влияе на следващия екип и на последващите записи.
Мениджърите трябва да подкрепят договорения процес, да вземат навременни решения и да помагат за премахване на бариерите. Проектът трябва също да планира временна загуба на производителност по време на обучението. Може да се случи кратък спад, докато хората учат новата система; добрата подготовка и отзивчивата поддръжка могат да помогнат на бизнеса да се стабилизира.
Измервайте внедряването и бизнес резултатите след старта. Примерите включват време за обработка на поръчки, точност на наличностите, брой дублирани записи, точност на производствения план, време на цикъла на фактуриране, отворени заявки за поддръжка и използване на договорения ERP процес. Сравнете ги с базовата линия, дефинирана преди проекта.
Служители и ръководител на проект, работещи по нов ERP поток в реална операция
Потокът от консултации на SIX в 7 стъпки
Потокът от консултации на SIX в 7 стъпки осигурява структуриран път от първоначалната посока до пълното усвояване. Той може да се използва за организиране на избора на ERP, миграцията и планирането на внедряването. Стъпките са: Определяне на посока, Картографиране на днешния ден, Приоритизиране на пропуските, Проектиране на утрешния ден, Подготовка, Планиране на доставката и Насърчаване на приемането. [5]
| Стъпка на SIX | Основен въпрос | Полезен резултат |
| Определяне на посока | Защо компанията се променя и какво е в обхват? | Бизнес цели, граници на проекта, мерки за успех и собственици на решения. |
| Картографиране на днешния ден | Как всъщност се случва работата сега? | Карти на процесите в текущото състояние, опис на системи и данни, изключения и рискове. |
| Приоритизиране на пропуските | Кои пропуски са най-важни за клиентите, служителите, контрола и растежа? | Класирани изисквания, приети пропуски и решения за персонализация. |
| Проектиране на утрешния ден | Как трябва да работи бъдещият процес в различните екипи и системи? | Потоци в целевото състояние, роли, одобрения, нужди от данни и дизайн на интеграцията. |
| Подготовка | Какви данни, хора, системи и решения трябва да са готови? | Правила за миграция, опис на интеграциите, план за ключови потребители и действия за готовност. |
| Планиране на доставката | Как ще бъде етапирана, тествана и управлявана работата? | Пътна карта, отговорности, зависимости, план за тестване, ценова база и подход за преминаване (cutover). |
| Насърчаване на приемането | Как компанията ще поддържа използването и ще се подобрява след старта? | Обучение според ролята, поддръжка, мерки за приемане и списък с подобрения. |
1. Определяне на посока
Договорете бизнес причината за промяната, преди да изберете ERP. Дефинирайте кои компании, обекти, екипи и процеси са включени. Изберете няколко измерими резултата и присвоете собственици, които могат да вземат решения. Ясната посока помага разговорите с доставчиците да останат фокусирани върху бизнес нуждите, вместо върху атрактивни, но несвързани функции.
2. Картографиране на днешния ден
Работете с хора от различни отдели, за да картографирате текущите процеси, системи, източници на данни, отчети, одобрения и заобиколни решения. Запишете както обичайния поток, така и изключенията. Това създава споделен поглед върху това къде текущата операция работи и къде губи време, контрол или информация.
3. Приоритизиране на пропуските
Сравнете това, от което се нуждае бизнесът, с това, което текущите или кандидат-системите могат да поддържат. Класирайте пропуските според ефекта им върху клиентите, операциите, разходите, риска, съответствието и бъдещия растеж. Тук компанията решава дали даден пропуск се нуждае от промяна на процеса, конфигурация, интеграция, персонализирана разработка или по-късна фаза на проекта.
4. Проектиране на утрешния ден
Проектирайте целевия процес, преди да конфигурирате софтуера. Дефинирайте кой изпълнява всяка стъпка, какви данни са необходими, какви одобрения се прилагат и как се движи информацията между бизнес областите. Целевият поток трябва да бъде приложим за служителите и достатъчно ясен за тестване. Той трябва да подобри операцията, а не просто да копира стария процес в нов интерфейс.
5. Подготовка
Идентифицирайте собствениците на данни, обхвата на миграцията, изискванията за интеграция, ключовите потребители, групите за обучение и нерешените решения. Започнете почистването на данните отрано. Прегледайте примерни записи с доставчика или партньора по внедряването. Подготовката дава на проекта по-реалистичен поглед върху усилията и намалява изненадите по време на изграждането и тестването.
6. Планиране на доставката
Превърнете договорения обхват в пътна карта с фази, собственици, зависимости, точки за тестване и мерки за успех. Решете дали да използвате пилотен проект, поетапно внедряване или по-широко преминаване (cutover). Определете правила за промени в обхвата. Планът за доставка трябва да посочва какво трябва да осигурят компанията и доставчикът, така че графикът и цената да имат ясна основа.
7. Насърчаване на приемането
Подкрепяйте потребителите след старта и проверявайте дали новите потоци се използват по проект. Проследявайте резултатите, решавайте проблеми и приоритизирайте подобренията. Стартирането е точка на преход, а не край на ERP програмата. SIX представя този модел от седем стъпки като структуриран път от определяне на посоката и картографиране на процесите до подготовка на данните, доставка и приемане. [5][6]
Често срещани капани при избор и миграция на ERP
| Капан | Защо причинява проблеми | По-добра практика |
| Избор по списък с функции или лъскава демонстрация | Демонстрацията може да не представя вашия действителен процес или продукта, включен в договора. | Използвайте сценарии по сценарий, базирани на вашите документирани работни потоци и представителни данни. |
| Искане на фиксирана цена, преди обхватът да е разбран | Неизвестни интеграции, данни и нужди от разработка могат по-късно да станат изключения или поръчки за промяна. | Първо поискайте бюджетен диапазон с предположения, а след това предложение с обхват след проучването. |
| Избор на софтуер без избор на партньор за доставка | Продуктът може да пасва, но екипът по внедряването може да няма съответните знания или капацитет. | Оценете действителния екип за доставка, референциите, метода на миграция, поддръжката и плана за надграждане. |
| Повторно изграждане на всяка наследена персонализация | Старите ограничения и ненужната сложност могат да станат постоянни части от новата ERP система. | Идентифицирайте какво прави всяка персонализация, кой се нуждае от нея и дали тя все още създава стойност. |
| Третиране на миграцията като техническо качване | Нечисти, дублирани или лошо картографирани данни могат да подкопаят доверието в новата система. | Присвоете собственици на данни, почистете записите, тествайте зарежданията и съгласувайте важните общи суми. |
| Оставяне на интеграциите за късно | Счупен или непълен интерфейс може да прекъсне потоците от поръчки, наличности, финанси или услуги. | Направете опис на интеграциите отрано и тествайте както отказите, така и успешните трансфери. |
| Подценяване на вътрешната работа | Служителите може да се наложи да подкрепят проекта, докато продължават ежедневните операции. | Резервирайте време за собствениците на процеси, ключовите потребители, тестването, обучението и решенията. |
| Третиране на стартирането като финална линия | Потребителите могат да се върнат към електронни таблици или да създадат заобиколни решения, ако поддръжката приключи твърде рано. | Планирайте стабилизиране, поддръжка според ролята, мерки за приемане и непрекъснато подобряване. |
Практически списък за проверка преди подписване
Преди да изберете ERP системата и да подпишете споразумение за внедряване, уверете се, че екипът на проекта може да отговори на тези въпроси:
- Какъв бизнес проблем решаваме и как ще измерваме напредъка?
- Картографирали ли сме действителния текущ процес, включително изключенията и заобиколните решения?
- Прегледали ли са служителите, които вършат работата, целевия процес?
- Класирани ли са задължителните изисквания и имат ли собственици сред посочените бизнес заинтересовани страни?
- Тествали ли сме реалистични сценарии от край до край във всяка система от краткия списък?
- Може ли доставчикът да идентифицира какво е стандартно, конфигурирано, интегрирано и персонализирано?
- Прегледали ли сме представителни данни и документирали ли сме отговорностите за миграция?
- Включени ли са в плана необходимите интеграции, тестване, обучение и поддръжка?
- Посочва ли предложението предположения, изключения, зависимости и правила за контрол на промените?
- Разбираме ли общите усилия по проекта и текущите разходи, а не само лиценза?
- Има ли тестван план за преминаване (cutover), решение за стартиране/нестартиране и подход за извънредни ситуации?
- Планирана ли е поддръжка след стартирането за периода, в който потребителите учат новите потоци?
Заключение: Изберете ERP системата, която пасва на начина, по който вашият бизнес трябва да работи
Успешното решение за ERP е структурирана оценка на това от какво се нуждае бизнесът, какво поддържат системите, кои процеси трябва да се променят и как компанията ще премине към нов начин на работа.
За съществуваща ERP система миграцията е шанс да се реши какво да се запази, подобри, интегрира, архивира или преустанови. Целта е да се дадат на служителите надеждни потоци, на ръководството — по-ясна информация, а на бизнеса — система, която може да продължи да развива.
В SIX потокът от консултации в 7 стъпки започва с посока и анализ на процесите, след което преминава през приоритети, бъдещ дизайн, подготовка, планиране на доставката и приемане. Това означава, че разговорът може да започне със самия бизнес — неговите процеси, данни, хора и системи — преди да бъдат финализирани решенията за конфигурация, индивидуална разработка и ценообразуване на проекта.
Правилният ERP проект започва, когато компанията може да обясни какво трябва да подобри, как протича работата ѝ днес и как трябва да изглежда един по-добър поток утре.
Говорете с експерт на SIX ERP за анализ на вашите бизнес потоци, преди да изберете или мигрирате вашата ERP система.
Референции
[1] Eric Kimberling, “Avoiding the Most Common ERP Software Selection Mistakes,” LinkedIn, June 7, 2025. https://www.linkedin.com/pulse/avoiding-most-common-erp-software-selection-mistakes-eric-kimberling-xb4kc/
[2] Dani Kaplan, “The Steps That Should be Taken Before Selecting New ERP Software,” LinkedIn, August 4, 2026. https://www.linkedin.com/pulse/practical-requirements-buying-new-erp-software-guide-dani-kaplan-kvkdc/
[3] Sam Gupta, “Migrating from Legacy ERPs: What Most Organizations Underestimate,” LinkedIn, August 22, 2026. https://www.linkedin.com/pulse/migrating-from-legacy-erps-what-most-organizations-sam-gupta-nqzgc/
[4] Chris Doig, “ERP Failure Begins Well Before the Software Is Selected,” LinkedIn, August 4, 2026. https://www.linkedin.com/pulse/erp-failure-begins-well-before-software-selected-chris-doig-16esc/
[5] SIX ERP, “Services Overview: The SIX 7-Step Consultation Flow.” https://six.ms/services-overview/
[6] SIX ERP, “From Spreadsheets to a Connected Business Transformation.” https://six.ms/blog/business-transformation-done-right/
[7] Microsoft Learn, “Optimize your implementation by using fit-to-standard and fit-gap analysis.” https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/process-focused-solution-fit-to-standard-fit-gap-analysis
[8] Microsoft Learn, “Manage configuration and migration data for Dynamics 365 projects.” https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/data-management-configuration-data-migration
[9] Microsoft Learn, “Transition to new solutions successfully with the cutover process.” https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/prepare-go-live-cutover-strategy
[10] SAP, “ERP Implementation Best Practices.” https://www.sap.com/resources/erp-implementation-best-practices
