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

Када има смисла софтвер по мери?

Готов софтвер је добар избор када су ваши процеси стандардни и нема потребе да мењате начин рада. Софтвер по мери је погоднији када имате специфична правила, више тимова, сложена одобрења или податке који се ручно преносе између 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 систем по мери.

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

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

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