А ако процесът ви го няма в ERP.net? Вече можете да си създадете приложение за него

Почти във всяка компания има поне един процес, който започва с изречението:

„Това го водим отделно.“

Понякога „отделно“ означава Excel. Друг път е таблица, вътрешен списък, малка самостоятелна система или файл, който всички знаят къде се намира.

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

ERP системата трябва да управлява стабилно основните бизнес процеси и данни – клиенти, продукти, продажби, доставки, складове, производство, проекти, финанси. Но реалният бизнес рядко приключва дотам.

Всяка компания има собствен начин на работа. Свои проверки. Свои изключения. Свои вътрешни процедури. И точно там обикновено се появяват процесите „извън системата“.

Сега Operator.net дава още един начин те да бъдат върнати обратно в контролирана софтуерна среда.

App Builder – специализираният агент на Operator.net за създаване на бизнес приложения чрез естествен език – вече може да изгражда Pro приложения със собствени таблици и собствени данни. А това променя доста повече от интерфейса на едно приложение.

Досега променяхме начина на работа. Сега можем да добавим и липсващата част от процеса

Първите приложения, които клиентите на ERP.net създадоха с App Builder, показаха много практичен начин за използване на AI в бизнес софтуера.

Не да измисля нов процес, а да направи съществуващия по-удобен.

Мобилен екран за търговец. По-лесна обработка на документи. Специализиран интерфейс за производство. Приложение за работа в сервиз или на терен.

Само два месеца след пускането на App Builder потребителите на ERP.net вече бяха създали над 450 приложения за реални ежедневни задачи.

В тези случаи основните данни вече са в ERP.net. Клиентът си е клиент, поръчката си е поръчка, продуктът си е продукт. App Builder създава различен начин човекът да работи с тях според конкретната роля и задача.

Pro Apps надграждат тази идея.

Те добавят управляван backend към приложението. В него могат да се използват собствени таблици, файлове, secrets, web requests и други възможности, когато конкретното приложение има нужда от повече от интерфейс върху съществуващите ERP данни.

И тук идва по-интересният въпрос:

Какво става, когато важна част от процеса изобщо няма естествено място в стандартния ERP модел?

Не всеки фирмен процес трябва да се превръща в ERP модул

Представете си производител, който работи с нестандартни изделия.

Материалите, продуктите, складовите движения и производствените задания имат естествено място в ERP.

Но преди да се стигне до производството, компанията може да има собствен процес за техническо одобрение: специфични параметри, няколко вътрешни проверки, файлове, решение на технолог и поредица от действия, характерни само за нейния начин на работа.

Или сервизна компания, при която стандартната сервизна поръчка трябва да бъде предшествана от специфична диагностика с различни въпроси и проверки според вида техника.

Или търговска организация, която иска да води посещенията на своите търговци – бележки от срещата, следващи действия и информация, която е свързана с клиента, но не е самият клиентски запис.

Последният сценарий присъства и в актуалната документация на Operator.net: мобилно приложение може да използва клиентите и поръчките директно от ERP.net, а бележките от търговските посещения да се пазят в собствена таблица на приложението.

Това е важната разлика.

Основните бизнес данни остават в ERP.net.

Специфичната информация, която принадлежи на конкретното приложение и неговия процес, вече може да има свое място.

Добрата персонализация не означава да копираме ERP системата

Собствените таблици не са покана бизнесът да започне да създава второ ERP.

Точно обратното.

При приложение, свързано с ERP.net, App Builder първо работи със съществуващия ERP модел и custom attributes. Партньори, продукти, поръчки, документи и другите основни бизнес обекти трябва да останат там, където им е мястото.

Документацията на Operator.net поставя това правило съвсем ясно: таблиците са предназначени за онова, което ERP.net не моделира – специфични за приложението записи, списъци, mappings, работни чернови или друга допълнителна информация. Таблицата може да сочи към ERP.net запис, но не трябва да бъде негово второ копие.

Именно това прави подхода интересен от бизнес гледна точка.

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

ERP.net пази общата бизнес истина.

Приложението решава конкретния проблем.

А ако за този процес изобщо не ви трябва ERP?

Тук промяната става още по-съществена.

Operator Apps вече не са ограничени само до приложения върху ERP.net. Актуалната документация позволява App Builder да създава приложения, които използват външни услуги или изобщо не работят с ERP.net.

При такова standalone приложение няма ERP модел, към който данните трябва да бъдат отнесени.

Тогава App Builder може да проектира собствените таблици на приложението и те на практика изпълняват ролята на неговата база данни.

Това променя и началната точка.

Не е задължително да кажете:

„Направи ми нов екран за тази информация от ERP.net.“

Можете да започнете с:

„Имаме този процес. Искам приложение за него.“

Например вътрешен регистър. Инструмент за проверки. Малка оперативна система за специфична дейност. Приложение за събиране и обработване на информация, която няма причина да живее в ERP.

А ако по-късно приложението трябва да използва друга система или външна услуга, Operator Apps могат да работят и с външни API.

Така границата вече не е „има ли подходящ ERP обект“, а какво всъщност трябва да прави приложението.

Човекът описва процеса. Operator.net се занимава с техническата структура

Зад всяко бизнес приложение стои модел на данните.

Какво трябва да се пази? Кои записи са свързани? По какво ще ги търсим? Как ще бъдат групирани?

Това обаче не означава, че човекът, който познава процеса, трябва да започне от таблиците.

Той може да започне от бизнеса:

„При всяка инспекция искам да пазим обекта, датата, проверяващия, резултатите от пет групи проверки, снимките, откритите проблеми и последващите действия.“

Когато приложението има нужда от собствено съхранение, App Builder може да предложи структурата на таблиците и я създава след потвърждение. За всяка таблица се пази и описание на схемата, така че следващите разговори за приложението да продължат върху същия модел.

Това е една от най-смислените промени, които AI внася в създаването на вътрешен бизнес софтуер.

Разговорът може да започне от процеса, а не от технологията зад него.

За бизнеса това означава по-къс път между:

„Трябва ни нещо за това“

и

„Нека видим как работи.“

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

Но първата работеща версия вече може да започне много по-близо до човека, който действително разбира проблема.

ERP като стабилна основа. Специфичният процес – там, където му е мястото

Тук се вижда и по-голямата идея зад Operator.net.

Не ERP.net да се превърне в система с безкрайно много стандартни екрани за всеки възможен фирмен сценарий.

И не бизнесът да се разпилее в десетки несвързани инструменти и таблици.

Идеята е различна.

ERP.net управлява основните бизнес данни, документи, процеси и логика.

Operator.net добавя AI агенти и приложения, които могат да бъдат създавани около конкретни задачи и начини на работа.

А когато специфичният процес има нужда от собствена информация, Pro приложението вече има къде да я съхранява.

Така един от най-познатите въпроси при избора и развитието на бизнес софтуер постепенно се променя.

От:

„Има ли системата такава функция?“

към:

„Как трябва да работи този процес при нас?“

И точно затова собствените таблици са много повече от поредната техническа новост в App Builder.