Повечето разговори за ERP започват на грешното място. Те започват с продукт — „да използваме ли Odoo, или нещо друго" — докато въпросът, който наистина има значение, идва преди това: какъв е бизнес проблемът и дали софтуерът изобщо е правилният начин да бъде решен? Разменете тази последователност и се озовавате със система, която е технически добре конфигурирана, но не поправя нищо, което реално е било счупено.
Това е погледът, който VitoshaBG прилага към всеки проект, и си струва да бъде обяснен ясно, защото е различна отправна точка от повечето разговори за ERP в България.
Въпросът преди въпроса
Собственик на бизнес рядко се обажда, защото иска ERP система. Той се обажда, защото нещо конкретно не работи — маржове, които не се връзват, срок за спазване на изисквания, който всеки път се превръща в паника в последния момент, растящ екип, който прекарва повече време в администрация, отколкото в клиенти. Софтуерът е средство, не целта. Истинската първа работа във всеки проект не е изборът на модули — а разбирането какво точно е счупено, защо, и дали свързана система наистина е решението, или реалният проблем се крие съвсем другаде: ценово решение, недостиг на персонал, процес, който никой не е документирал.
Това има значение, защото двете най-чести грешки при внедряване на ERP седят в двата края на една и съща грешка — да третираш софтуера като отправна точка вместо бизнес проблема.
Два начина, по които това се проваля
Купуване на повече, отколкото бизнесът се нуждае. Демонстрация на платформа с богата функционалност наистина впечатлява, и е лесно да си тръгнеш с желанието да конфигурираш осем модула наведнъж. Резултатът често е проект, който тръгва в експлоатация, без нито един от тях да работи правилно, защото обхватът е надминал това, което бизнесът — и екипът му — реално могат да поемат. Решението не е „купи по-малко софтуер"; то е в разбирането кои проблеми са спешни и реални, преди обхватът да бъде решен.
Купуване на по-малко, отколкото бизнесът се нуждае. Обратната грешка е също толкова скъпа и по-рядко обсъждана. Бизнес закърпва един симптом — единичен инструмент за отчитане, самостоятелно приложение за фактуриране — без да разпознае, че реалният проблем е няколко свързани процеса, не един изолиран. Проблем с маржа често е проблем със снабдяване-плюс-склад-плюс-счетоводство, облечен в един костюм. Поправянето само на видимия симптом означава, че същият разговор се случва отново след осем месеца, с нов инструмент и същата основна празнина.
Избягването и на двете грешки изисква едно и също нещо: разбиране на бизнеса, преди да се препоръча софтуерът, а не съпоставяне на списък с функции със заявено желание.
Как всъщност изглежда „оценка на бизнеса"
На практика това означава да се задават въпроси, които нямат нищо общо с Odoo, преди да се зададе каквото и да е, което има:
- Кое решение не можете да вземете уверено точно сега? Не „каква справка искате", а кое решение се взима на догадки вместо на данни — ценообразуване, персонал, презареждане на стока, да/не за сделк.
- Къде се въвежда една и съща информация повече от веднъж? Това обикновено разкрива реалната форма на проблема по-бързо от всяко заявено изискване, защото показва къде процесите тихо са се разкачили един от друг..
- Каква е цената на настоящата ситуация, конкретно? Не в абстрактен план — в часове, прекарани в равнения, в забавени решения, в поет комплайънс риск. Ако тази цена не може приблизително да се оцени, си струва да се проучи, преди разговорът за софтуер да продължи.
- Какви регулаторни или специфични за индустрията задължения съществуват, на които общ отговор няма да отговори? Тук много препоръки за софтуер тръгват в грешна посока — функция, която е „достатъчно добра" по принцип, не е достатъчно добра срещу конкретно българско изискване за отчетност.
Едва след като те бъдат истински разбрани, разговорът се обръща към това какво трябва да прави системата — и в този момент изборът на софтуер обикновено е очевиден, защото изискванията са точни, а не предполагани.
Защо в дълбочината на една платформа всъщност е смисълът
Струва си да се каже директно: Odoo е наистина сложен софтуер под чистия си интерфейс — десетки взаимосвързани модула, гъвкав модел на данните и достатъчно дълбочина за конфигуриране, за да се изгради почти всяка бизнес логика върху него. Тази сложност понякога се третира като недостатък, нещо, което трябва да се минимизира или скрие от клиента. Не би трябвало - това е предимство.
Причината оценката, поставяща бизнеса на първо място, да има толкова голямо значение е точно защото Odoo може да прави далеч повече, отколкото се нуждае който и да е отделен бизнес в първия ден. Повърхностно внедряване докосва само повърхността — стандартно фактуриране, общ процес на продажби. Дълбочината отдолу е това, което прави възможно изграждането на нещо, което наистина отговаря на реалната механика на бизнеса, вместо да принуждава бизнеса да се адаптира към настройките по подразбиране на софтуера. Сложността, използвана съзнателно, е това, което превръща общ ERP в система, която прилепва точно към бизнеса. Използвана небрежно, тя е това, което произвежда „капана на демонстрацията", описан по-горе. Разликата е изцяло в това дали бизнес проблемът е бил разбран първо.
Защо това има още по-голямо значение в регулирана, специализирана работа: случаят със Софтуер за управление на кредити
Този подход не е теоретичен — той е същата дисциплина, която VitoshaBG прилага в най-взискателните си проекти, и си струва да бъде конкретизиран с един от тях: Софтуерна система за управление на кредитиране и консултации за кредитен бизнес.
Бизнесите, търсещи Софтуер за управление на кредити от финансови институции рядко търсят общи счетоводни функции. Това, което всъщност се опитват да решат, обикновено се групира около последователен набор от проблеми: бавни цикли на отпускане и одобрение на кредити, които задържат растежа; нарастваща просрочена задлъжнялост, която не се улавя достатъчно рано, защото рискът на портфейла не е видим в реално време; високи оперативни разходи от ръчна обработка на всеки етап — отпускане, обслужване, събиране; оскъдни кредитни данни за нови или недостатъчно обслужвани от банковата система кредитополучатели, които стандартните модели за скоринг не обработват добре; кредитни продукти, които не могат да се адаптират към местните пазарни условия без скъпа custom разработка; и разкачени инструменти през целия жизнен цикъл на кредитирането, при които онбординг, скоринг, обслужване и събиране живеят в отделни системи, които не комуникират помежду си.
Добавено върху всичко това, конкретно в България, е регулаторна отчетност, която не прощава отговор „достатъчно добър" — Relief, AnaCredit Daily и AnaCredit Monthly пред Българската народна банка, всяко със своя собствена структура на данни и изисквания за подаване. Кредитиращата финансова институция няма лукса на софтуер, който е приблизително работи правилно.
Тук Кредитната Система за финансови институции, на VitoshaBG, изградена върху Odoo, идва от наистина различна отправна точка спрямо обща ERP конфигурация. Основната кредитна логика — модели за скоринг, разпределение на плащания между главница, лихва и такси, изчисляване на погасителен план — трябваше да бъде разбрана и правилно моделирана преди да бъде конфигуриран какъвто и да е модул на Odoo. Дълбочината на Odoo е това, което прави възможно правилното изграждане на това в рамките на една свързана платформа, вместо сглобяване на отделни инструменти за скоринг, обслужване и отчетност за съответствие; но тази дълбочина се изплаща единствено защото реалната механика на кредитирането и изискванията за отчетност пред БНБ бяха отправната точка, а не последваща мисъл, добавена върху стандартна CRM-и-счетоводна настройка.
Това е последователността, поставяща бизнеса на първо място, в най-конкретната му форма, и е и причината система, изградена по този начин, да решава реалните проблеми, които финансовите институции - кредиторите всъщност търсят — по-бързо отпускане чрез автоматизирани работни процеси, видимост на портфейла в реално време вместо изненади в края на месеца, и отчетност, която удовлетворява изискванията на БНБ като страничен резултат от начина, по който са структурирани данните, а не като отделно ръчно упражнение, добавено впоследствие.
Същата дисциплина се прилага в по-малък мащаб към всеки проект, дори такива без никаква регулаторна сложност — разбери механиката на реалния проблем първо, после реши какво трябва да прави системата.
Какво означава това за начина, по който работим
Това е практическата разлика между бизнес консултантска компания, която освен това внедрява Odoo, и внедрител, който започва всеки разговор със софтуера. Тя се проявява по няколко конкретни начина::
- Оценката на обхвата започва с вашите числа, не с нашия списък от модули. Преди каквато и да е препоръка, въпросът е какво реално ви коства време, пари или риск — конкретно, не общо.
- „Не" понякога е правилният отговор. Ако реалният проблем на бизнеса е ценово решение или недостиг на персонал, а не системна празнина, да го кажем е по-полезно от продажбата на конфигурационен проект, който няма да го реши .
- Сложността се съпоставя със сложността. Бизнес с наистина взаимосвързани проблеми — маржове, множество локации, регулаторна отчетност — се нуждае от наистина интегрирана система. Бизнес с една изолирана болезнена точка често все още не се нуждае от пълната платформа, и налагането ѝ рядко помага.
- Специализираните знания идват преди конфигурацията. Независимо дали става дума за българско ДДС и НАП отчитане, кредитна отчетност пред БНБ, или специфичен за индустрията работен процес, разбирането на реалните правила, по които оперира бизнесът, е това, което прави системата правилна — не просто функционална.
Отправната точка, която наистина работи
Ако има едно нещо, което си струва да се вземе от всичко това, то е, че правилният първи въпрос никога не е „коя ERP система да използваме". А „какво конкретно ни коства най-много точно сега — и софтуерът наистина ли е начинът да се реши това?" Понякога честният отговор води директно към Odoo, конфигурирана около реалните, конкретни нужди на бизнеса — понякога толкова задълбочено, колкото пълна Софтуерна сисетема за кредитиране от финанасови институции. Понякога води другаде първо — поправка на процес, преглед на ценообразуването, бизнес план — и разговорът за софтуер идва по-късно, след като основата отдолу е стабилна.
Два свързани въпроса се появяват достатъчно често сами по себе си, за да сме писали за тях отделно: дали вашият бизнес: показва признаците на надрастване на инструментите, които използва в момента, и колко всъщност струва внедряването на Odoo след като реалният обхват е разбран.
Ако не сте сигурни кое от двете е вярно за вашия бизнес точно сега, точно това е разговорът, който си струва да проведем, преди да бъде избрана каквато и да е система: запишете си безплатна консултазия с VitoshaBG.