Како тече развојот на софтвер по нарачка?

Кога има смисла софтверот по нарачка?

Готовиот софтвер е добар избор кога вашите процеси се стандардни и не се наметнува да го менувате начинот на работа. Софтверот по нарачка е посоодветен кога имате специфични правила, повеќе тимови, сложени одобрувања или податоци што рачно се префрлаат меѓу Excel, е-пошта, ERP и CRM.

Пример е систем што ги поврзува побарувањето, увидот, понудата, монтажата и гаранцијата. Друг е диспечерски панел со нарачки, GPS-мапа, возачи и фактури. Кај таквите процеси, една готова програма често покрива само дел од потребите, а остатокот се управува со табели и телефонски разговори.

Изработката може да биде веб-систем достапен преку прелистувач, мобилна апликација, интерен портал, клиентски портал или нивна комбинација. По потреба системот се поврзува со плаќања, курири, телефонија, сметководствен софтвер и други услуги преку API.

Како се прецизираат целите и барањата?

Најпрво се опишува како фирмата работи во моментот. Се разгледуваат улогите во тимот, документите, одобрувањата, исклучоците и местата на кои се губат информации. Важно е да се види не само што прави управителот, туку и што внесува операторот, трговецот, сметководителот или техничарот.

Потоа се формулира целта на системот. Таа треба да биде конкретна: сите барања да се гледаат на едно место, понудите да се следат, фактурите да се создаваат од потврдена нарачка или да се отстрани рачното копирање меѓу две програми.

Барањата се делат на задолжителни и пожелни. Задолжителните влегуваат во првата верзија. Пожелните се планираат за следната фаза, ако не се потребни за почетокот. Така се ограничува ризикот проектот неконтролирано да се прошири.

Во оваа фаза дополнително се прецизираат правата за пристап, потребните извештаи, миграцијата на податоци, мобилниот пристап, резервните копии, начинот на најавување и интеграциите. Ако системот ќе обработува лични или финансиски податоци, барањата за пристап и дневникот на дејства се планираат уште на почетокот.

Како се планира веб-систем по нарачка?

По прецизирањето на процесите се опишуваат главните екрани и дејства. За секоја улога треба да биде јасно што гледа, што може да создава, што одобрува и какви известувања добива. Така се гради логиката на системот пред да се премине на визуелниот дизајн.

Кај посложените проекти се изработува прототип на клучните текови. На пример, трговецот создава понуда, клиентот ја отвора, управителот ја одобрува, а сметководителот ги добива податоците за фактурата. Прототипот овозможува овие чекори да се разгледаат со вистинските луѓе што ќе работат со системот.

Се планира и техничката основа: база на податоци, корисници и улоги, API, датотеки, известувања, дневници, хостинг и резервни копии. Кај јавен систем се размислува и за оптоварувањето, заштитата на формуларите и однесувањето при грешка.

Развојот ретко треба да започне со сите можни функции. Поразумно е првата верзија да го покрива главниот процес и да ја користи тимот. По добиени повратни информации се додаваат автоматизации, дополнителни извештаи и нови интеграции.

Како се одвива самиот развој?

1. 01
   Подготовка на основата

   Се создаваат базата на податоци, корисниците, улогите, главните поставки и структурата на проектот. Се подготвува средина во која новите функционалности можат да се проверуваат одделно од активниот систем.

2. 02
   Развој на главните процеси

   Се градат модулите што носат најголема вредност: барања, клиенти, зделки, задачи, магацин, распоред, документи или други делови според процесот. Секој модул се поврзува со останатите, наместо да биде изолиран екран.

3. 03
   Интеграции и автоматизација

   Се додаваат API-врски со плаќања, курири, телефонија, е-пошта, сметководство или надворешни каталози. Се автоматизираат повторливите дејства како создавање фактура, испраќање известување или промена на статус.

4. 04
   Постепено претставување

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

5. 05
   Подготовка за реална употреба

   Се проверуваат корисниците, податоците, поставките, пристапите и упатствата. Се определува кој од тимот ќе го следи системот и кој ќе ги одобрува идните промени.

Како се тестира софтверот пред воведување?

Тестирањето не е само проверка дали копчето се притиска. Се проверува целиот процес со реалистични сценарија: создавање клиент, промена на статус, одбиена нарачка, делумно плаќање, артикл што недостасува во магацин или корисник без право за одредено дејство.

Се проверуваат различни улоги, мобилни уреди, прелистувачи, известувања, датотеки и интеграции. При промена на системот се прави и повторна проверка на веќе функционалните делови. Така се намалува ризикот нова функционалност да оштети стар процес.

Пред пуштањето корисно е клучните вработени да работат со системот во тестовна средина. Тие забележуваат работи што не се гледаат во техничкиот опис: поле што недостасува, нејасен статус или непотребен чекор при секојдневна задача.

Како се одвива имплементацијата?

Имплементацијата опфаќа поставување на реалната средина, увоз на податоци, креирање корисници и проверка на пристапите. Ако се пренесуваат информации од Excel или стар систем, претходно се чистат дуплираните, нецелосните и неправилно форматираните записи.

Обично се одредуваат датум за преминување и јасен план за постапување при проблем. Во зависност од ризикот, може да има краток период во кој стариот и новиот систем работат паралелно. Тимот добива упатства и конкретни примери поврзани со неговата работа.

По започнувањето се следат грешките, бавните операции и прашањата на корисниците. Во овој период често се прават мали корекции на полињата, известувањата, дозволите и извештаите. Тоа не значи дека проектот е лошо испланиран. Реалната употреба покажува детали што не можат целосно да се видат на демонстрација во канцеларија.

Што опфаќа одржувањето по развојот?

Одржувањето може да опфаќа следење, резервни копии, ажурирања, отстранување грешки и мали промени во системот. Кај веб-апликација се следат серверот, SSL сертификатот, пристапите и надворешните интеграции.

Одржувањето не е исто што и нов развој. Додавањето нов модул, нова улога или сложена интеграција се планира одделно. За тековно техничко одржување, ориентациската цена е 100–350 € месечно, а конкретниот износ зависи од бројот на системи, потребното време за реакција и обемот на вклучените активности.

Добро е уште на почетокот да се утврди кој ги поседува кодот, базата на податоци, пристапите и документацијата. При изработка на софтвер по нарачка, системот се гради околу Вашиот процес, а овие прашања треба да бидат дел од понудата и условите.

Како се одредуваат рокот и цената?

Рокот зависи од бројот на модули, сложеноста на правилата, интеграциите, миграцијата на податоци и брзината на повратните информации. Проект со неколку улоги и стандардни извештаи се планира поинаку од платформа со мобилна апликација, плаќања, геолокација и надворешни API врски.

Цената се одредува по разговор, преглед на процесите и опис на опсегот. Кај софтвер по нарачка, ориентациската цена е 3.000–29.300 €. Пониската граница е можна при ограничен опсег и готови компоненти, а повисоката се достигнува при повеќе улоги, сложена деловна логика, интеграции, мобилен дел, миграција и посебни безбедносни барања.

Табелата е ориентациска, а не автоматска понуда. Важно е да се утврди што е вклучено: анализа, дизајн, програмирање, тестови, увоз на податоци, обука, хостинг, гарантен период и одржување. Така споредувате реални опсези, а не само крајни износи.

Како изгледа еден реален проект?

Кај LiftexPro – ERP за лифтовски компании, системот опфаќа планирање на прегледи, управување со згради, мобилна апликација за техничари и автоматско фактурирање. Ова е добар пример зошто изработката започнува од целиот работен процес, а не од одделен екран.

Кај ваков систем, различните улоги имаат различни задачи. Диспечерот планира, техничарот работи на терен, управителот го следи извршувањето, а сметководството ги користи податоците за фактурирање. Ако овие делови не се поврзани, компанијата повторно ќе препишува информации.

Кога главниот проблем е расцепканата информација меѓу програмите, се планираат API интеграции и поврзување софтвер. Кога системот треба да управува со склад, продажба и улоги во една средина, соодветна почетна точка е ERP систем по нарачка.

Како да подготвите барање за развој?

• Опишете кој процес одзема најмногу време или доведува до грешки.
• Наведете ги улогите што ќе го користат системот и што треба да може да прави секоја од нив.
• Наведете ги програмите, датотеките и услугите со кои треба да има поврзување.
• Дадете пример за реален случај од почеток до крај.
• Наведете кои функции се задолжителни за првата верзија.
• Утврдете кои податоци треба да се пренесат и кои извештаи се потребни.
• Побарајте понуда со опсег, фази, рок, услови за прифаќање и одржување.

Колку појасно е опишан процесот, толку посмислено може да се процени проектот. Не е потребно да ги знаете техничките термини. Важно е да покажете како работи фирмата и што треба да се промени.