Kā definēt MVP ERP programmatūrai

Kā definēt minimālo dzīvotspējīgo produktu (MVP) uzņēmumu resursu plānošanas (ERP) programmatūrā, ja visas funkcijas ir savstarpēji saistītas un ļoti sarežģītas?

Patiesībā nav svarīgi, vai izmantojat Kanban, Scrum vai citu Agile praksi, mērķis ir viens un tas pats: pēc iespējas ātrāk radīt MVP, pierādīt uzņēmumam, ka šis risinājums ir piemērots, un pēc tam iterācijās to uzlabot, līdz tas ir tādā līmenī, lai klienti būtu apmierināti. Vispirms jūs to pilnveidojat līdz minimālajam tirgojamajam produktam (MMP) un pēc tam līdz pilna apjoma pilnībā funkcionālam produktam.

Attiecībā uz ERP programmatūru to var izdarīt vairākos veidos atkarībā no projekta specifikas. Agile izmanto daudzas metodes, lai palīdzētu noteikt darbības jomu un MVP. 

Visvienkāršākais veids būtu pret ERP izturēties kā pret jebkuru citu programmatūru, definējot pilnu darbības jomu un MVP, izmantojot stāstu kartēšanu vai citu tehniku, un pēc tam projekta laikā projekta pilnveidošanas sesijās saskaņot pieejamo funkcionalitāti un labāko praksi ar klientu vajadzībām, kurām ir vislielākā vērtība. Jūs pat varat labāk sagatavoties precizēšanas sesijām, jo jums jau ir produkts, ko parādīt - vienkārši konfigurējiet to pēc iespējas labāk un pārrunājiet to ar klientu.

MVP varētu ietvert dažas pamatfunkcijas, kas ļautu klientam "izbaudīt" ERP programmatūru vai nu pilnā, vai ierobežotā (klientam visvērtīgākā) apjomā. Labākajā gadījumā uzņēmums varētu sākt izmantot programmatūru daļējā apjomā (minimālā tirgū realizējamā funkcija (MMF) vai minimālais tirgū realizējamais produkts (MMP)), paralēli izmantojot veco programmatūru vai citus rīkus, piemēram, Excel. Attiecībā uz MVP to var uzskatīt par prototipu, koncepcijas pierādījumu, beta versiju vai 0.1 versiju - neatkarīgi no tā, kurš variants klientam sniedz vislielāko sākotnējo vērtību. Pastāv īpašas metodes darbības jomas kartēšanai un prioritāšu noteikšanai, kā arī MVP definēšanai.

Piemērs

Kā piemēru var minēt ERP projektu ražošanas uzņēmumam, kas ražo ūdeni. Uzņēmums vēlas, lai ERP aptvertu visas tā darbības, tostarp ražošanu, noliktavu, loģistiku, finanses, personālu, pārskatus un konsolidāciju. Uzņēmums darbojas piecās valstīs vai piecās pilsētās. 

Jūs varētu organizēt dažu dienu semināru, lai augstā līmenī noteiktu pilnu darbības jomu. Tās laikā jūs arī definētu MVP. 

Šajā piemērā tas varētu būt šāds iestatījums:

  • preču katalogs ar pamatinformāciju
  • pamata noliktavas - tikai krājumu uzskaitei.
  • pamatiepirkumi, lai preču iegāde būtu iespējama visvienkāršākajos scenārijos.
  • pamata pārdošanas modelēšana, lai simulētu ražoto preču pārdošanu. 
  • kontu plānu - tikai iepirkumu un izmaksu aprēķinu vajadzībām.
  • un, iespējams, vienkāršs materiālu saraksts, lai parādītu, ka sistēma var pārvērst izejvielas produktos.

Nav datu migrācijas. Šī MVP funkcionalitāte varētu būt jau gatavas ERP funkcijas ar dažiem konfigurētiem un izstrādātiem pielāgojumiem. 

Jūs apņematies izveidot šo MVP un piegādāt to dažu nedēļu laikā. Kādu vērtību tas dod? Klients var izmēģināt pamata funkcionalitāti un gūt priekšstatu par sistēmu. Viņš var pamanīt dažādas funkcijas, uzdot dažus jautājumus, atcelt iepriekšējās prasības un radīt jaunas, pamatojoties uz šo praktisko pieredzi. Dažos retos gadījumos, ja sistēma ir labāka par to, ko klients izmantoja iepriekš (piemēram, e-pasti un dažas Excel izklājlapas), klients var saskatīt produkta vērtību un pat pāriet uz šīs MVP versijas izmantošanu.

Kas tālāk

Nākamajā laidienā varētu sākt darboties vismazākā ražotne kā izmēģinājuma versija ar datu migrāciju un minimālo funkciju kopumu (lai paveiktu visu darbu, joprojām varētu izmantot Excel vai cita veida apdarināšanas rīkus), un pēc tam laidiens pēc laidiena nodrošināt to darbības jomu, ko klients novērtē visvairāk.

Vai pamanījāt, ka klients var spēlēties ar programmatūru jau trīs nedēļas pēc projekta darba uzsākšanas? Waterfall parasti neparedz šādu iespēju.

Paturiet prātā, ka Agile nav piemērots visām ERP ieviešanām. Agile ir vispiemērotākais tiem, kuriem ir vidējs vai augsts nenoteiktības līmenis attiecībā uz funkcionalitātes apjomu un uzņēmējdarbības specifiku.

Atcerieties, ka šis ir tikai vienkāršots piemērs. Mēs labprāt iedziļināsimies reālā piemērā un palīdzēsim jums definēt darbības jomu un MVP.