Защо е нужен анализ на процесите, преди да започне ERP проектът?

В демото на ERP всичко работи гладко; проблемът е, че фирмата в демото не е вашата. Анализът на процесите е работа, която преди преминаването към софтуер извежда стъпка по стъпка как всъщност се движи работата от поръчката до събирането на плащането. Дали един ERP проект ще върви здраво, често зависи от качеството на тази работа.

В тази статия обясняваме защо анализът не бива да се прескача, какво се извежда в него и какви документи трябва да имате накрая. Разглеждаме подхода през принципите на YazSis ERP, който изграждаме като архитектура, приспособена към бизнеса.

Какво става, ако анализът се прескочи?

Софтуерът се инсталира, екраните се отварят, всички влизат. След няколко седмици част от служителите се връщат към старите си навици. Защото софтуерът е изграден не според начина, по който работата тече в действителност, а според начина, по който е разказана на хартия. Четирите проблема по-долу са най-честите последици от това.

• Обхватът се измества: искания от типа „добавете и това“ се трупат по средата на проекта, срокът се удължава и какво влиза в първата фаза, става спорен въпрос.
• Започва двойно записване: работата, която няма място в системата, пак се върши в Excel; двата записа с времето се разминават и не е ясно кой е верният.
• Потребителят се съпротивлява: вместо да улеснява работата на потребителя, екранът го кара да попълва излишни полета. Тогава софтуерът се възприема като допълнителна тежест.
• Отговорността остава неясна: кой дава одобрението и кой решава изключенията, се обсъжда чак след пускането в работа, а това решение можеше да се вземе в началото на проекта.

Пет стъпки в анализа на процесите

1. Начертайте потока такъв, какъвто е. Запишете от кой човек към кой човек и с какъв инструмент днес се движат поръчката, доставката и движението на склада. Важен е потокът, който съществува в действителност, а не този, който трябва да бъде.
2. Съберете изключенията. Случаи, които не са „нормални“, като връщане, частично изпращане, ценова разлика или спешна поръчка, могат да съставляват голяма част от ежедневната работа. Софтуерът се затруднява най-много точно там; затова за тях трябва да се води отделен списък.
3. Изяснете одобренията и правомощията. Над каква сума кой одобрява, кой може да дава отстъпка, кой може да прави корекция на наличност? Тези отговори трябва да се вържат за роля, а не за човек.
4. Изброете източниците на данни. Къде се пазят списъкът с клиенти, картонът на продукта и ценовата листа? Кое е актуално и кой го обновява? Местата, където една и съща информация живее на няколко места, са тези, които в системата ще се сведат до един запис.
5. Решете какво ще измервате. Ако още в началото изберете няколко показателя, които ръководството иска да вижда всяка седмица, екраните и отчетите се изграждат според тях; добавянето на отчети по-късно винаги е по-трудно.

Малък пример: одобрение на отстъпка

Клиент иска намаление. Търговският представител пише на ръководителя във WhatsApp, ръководителят казва „добре“ и представителят подготвя офертата. Никой не е определил това като процес, но то работи всеки ден. Ако този поток не бъде описан при преминаването към ERP, в системата или няма никаква стъпка за одобрение, или има такава, която никой не използва. Анализът слага това невидимо правило на хартия и го прави годно да бъде вградено в софтуера. Същият метод важи и за другите тихи правила, като корекцията на наличност, избора на доставчик и приемането на връщане: първо се отговаря на въпроса кой по какво решава, а след това това решение се записва в системата като стъпка.

Процес, който не можете да обясните на софтуера, не работи в софтуера.

Кой трябва да участва в анализа?

Процеса го познават най-отблизо хората, които вършат тази работа всеки ден. Затова анализът не бива да остава само на ниво ръководство и ИТ; в процеса трябва да участват и търговският представител, складовикът, човекът по доставките и счетоводителят. Ръководството казва как работата трябва да върви, служителят казва как върви в действителност. Разликата между двете е истинският списък със задачи на проекта. Понякога тази разлика не е нужда от софтуер, а просто липсващо правило или излишна стъпка за одобрение; да я видите по време на анализа е много по-малко усилие, отколкото да я забележите след инсталирането.

Какво трябва да имате в ръцете си след анализа?

Добрият анализ не свършва с устни срещи, а с конкретни документи. Тези документи стават опора както за инсталирането на ERP, така и за следващите промени; когато дойде нов служител или нов ръководител, именно те обясняват защо системата е изградена така:

• Карти на процесите от продажбата до събирането на плащането и от доставката до получаването.
• Списък на изключенията и особените случаи; за всеки от тях кой взема решението.
• Таблица на ролите и правомощията: кой какво вижда, кой какво одобрява.
• Карта на интеграциите, която показва източниците на данни и как те ще бъдат свързани помежду си.
• Обхватът на първата фаза и редът на областите, които ще се добавят в следващите фази.

Нашият подход: ERP да пасва на бизнеса

YazSis ERP изграждаме по четири принципа. Тези принципи определят и какво ще бъде решено в края на анализа на процесите:

• Запазваме съществуващата система: ако има работещ ERP, той не се премахва; липсващите процеси се допълват.
• Разширяваме с отделен модул: процесът, който стандартният продукт не покрива, се разработва според организацията.
• Обединяваме данните: общият поток на информация се изгражда чрез API и интеграции с бази данни.
• Измерваме и подобряваме: управленските отчети правят видими тясното място и резултата.

Ако искате да картографираме заедно процесите ви и да определим обхвата на първата фаза, можете да се свържете с нас през страницата YazSis ERP.