Gatavs produkts vai pasūtījuma programmatūra: kad ko izvēlēties
Ja process ietilpst gatavā rīkā, ņemiet to. Pasūtījuma programmatūra ir pamatota tad, kad process ir Jūsu konkurētspēja vai gatavie produkti prasa pārāk daudz kompromisu.
Ja process ietilpst gatavā rīkā, ņemiet to. Pasūtījuma programmatūra ir pamatota tad, kad process ir Jūsu konkurētspēja vai gatavie produkti prasa pārāk daudz kompromisu.
Jūs pērkat CRM, jo pārdošanas vadītājs vairs netiek galā ar piezīmēm, un pēc trim mēnešiem blakus sistēmai stāv Excel ar trim cenu sarakstiem un mape ar rēķiniem, kurus kāds pārkopē grāmatvedībā. Produkts nav sliktāks par to, par ko tas tika pārdots, jo tas zina klientu, darījumu un nākamo zvanu, bet tas nezina Jūsu procesu, jo šis process nebija tas, ko ražotājs būvēja simtiem uzņēmumu, un šī atstarpe ir visa šī raksta tēma: vai Jūs pērkat rīku savam procesam, vai procesu savam rīkam, nevis funkciju saraksta caurumu, kuru var aizpildīt ar vienu pielāgojumu. Ja caurums ir savienojums starp sistēmām, kuras jau dara savu darbu, tas nav arguments būvei: vispirms savienojam to, kas jau ir.
Gatavs produkts vai pasūtījuma programmatūra: kad ko izvēlēties, nav jautājums par to, kura poga izskatās modernāka, un nav arī jautājums par to, vai Jūs “esat pietiekami lieli, lai būvētu paši”. Mūsu atbilde ir tā pati, ko esam uzrakstījuši pakalpojuma lapā: ja Jūsu process ietilpst gatavā rīkā, ņemiet gatavo rīku, tas būs lētāk, un pielāgota sistēma ir pamatota tad, kad process ir Jūsu konkurētspējas daļa vai gatavie risinājumi prasa pārāk daudz kompromisu, un šis teikums nav pārdošanas triks, lai pēc tam tomēr pārdotu būvi, bet tests, ar kuru mēs zaudējam rindas, kurās būtu jāuzraksta vēl viens CRM, un paturam tās, kurās šis tests ir izturēts.
Šis raksts nav interneta veikala platformas salīdzinājums, jo to jau esam uzrakstījuši citur, un tas nav arī pasūtījuma programmatūras cenrādis, jo tāda raksta mums nav un nebūs, tāpēc ka cenas no galvas neizdomājam, un tas arī nav solījums, ka sava sistēma vienmēr uzvar. Mēs pārdodam gan gatavā produkta ieviešanu, gan būvi no nulles, un godīgs teksts sākas ar to, ka dažkārt dārgākais pakalpojums, ko varam Jums pārdot, ir tas, kuru Jums nevajag, tāpēc tālāk ir robeža, pēc kuras šo izvēli var izdarīt, pirms kāds Jums pārdod sprintu.
Gatavs produkts vai pasūtījuma programmatūra: kad ko izvēlēties
Ņemiet gatavo produktu, ja process ietilpst tajā, un pasūtiet programmatūru, ja process ir Jūsu konkurētspēja vai gatavie rīki prasa pārāk daudz kompromisu: tā ir visa atbilde, un pārējais šajā rakstā ir tas, kā šo teikumu pārbaudīt pret konkrētu darbu, ne pret prezentāciju. Salīdzinājums, kurš sākas ar funkciju tabulu, beidzas, pirms sācies, jo tabula rāda to, ko ražotājs ir nosaucis, ne to, kurš pēc gada izlems Jūsu nākamo izmaiņu.
Sekas no nepareizās puses nav simetriskas, jo gatavais rīks, kurā Jūs esat ielikuši savu procesu ar varu, kļūst par abonementu plus Excel plus cilvēku, kurš tur abus kopā, un šis cilvēks pēc gada ir dārgāks par jebkuru licenci, bet pasūtījuma sistēma procesam, kurš jau dzīvo grāmatvedībā, pasta programmā un standarta CRM, ir būve, kuru Jūs uzturēsiet paši, lai gan tirgū to jau uztur kāds cits. Pirmajā gadījumā Jūs esat nopirkuši produktu un pēc tam uzrakstījuši otru sistēmu tam blakus, otrajā Jūs esat uzrakstījuši sistēmu tur, kur pietika ar licenci, un abas kļūdas maksā ilgāk, nekā izskatās piedāvājumā.
Mēs šo robežu nosaucam tāpēc, ka esam redzējuši abus galus vienā nedēļā: uzņēmumu, kurš gribēja “savu HubSpot”, lai gan viņam vajadzēja HubSpot, un uzņēmumu, kurš trīs gadus locīja gatavu ERP ap savu cenu tabulu un beidzot nāca pēc tās pašas tabulas kā pēc jauna projekta, ne tāpēc, ka “ERP nemāk”, bet tāpēc, ka kompromisu jau bija vairāk par konfigurāciju. Neviens no šiem stāvokļiem nav sliktas gribas rezultāts, jo abi sākas ar teikumu “mums vajag sistēmu”, kurš vēl nav tests, un tests sākas tikai tad, kad Jūs uzrakstāt procesu vienā lappusē bez rīka nosaukuma un pēc tam meklējat, kurš rīks šo lappusi jau dara.
Pirms iepirkuma uzrakstiet, kas sistēmai ir jādara pirmajā dienā, ko tā nedrīkst aizmirst otrajā gadā, un kurš drīkst to mainīt bez sveša laidiena, jo, ja atbildes ietilpst produktā, kuru var konfigurēt, ņemiet produktu. Ja jautājums ir katalogs, cenas, pasūtījums un piegāde e-veikalā, tas ir veikala tests, un mēs to nepārrakstām; ja atbildes ir process, kuru konkurents nedrīkst nopirkt kā gatavu rīku, tikai tad ir jēga runāt par sprintu. Šis raksts tālāk pārdod šo kārtību, ne rīku.
Kas ir gatavais produkts un kas ir pasūtījuma programmatūra
Gatavais produkts ir programmatūra, kuru kāds jau ir uzrakstījis daudziem un kuru Jūs iegādājaties vai abonējat, lai to lietotu bez būtiskas pārbūves, un Viedās administrācijas un reģionālās attīstības ministrijas IKT izdevumu vadlīnijās, kas 2026.gada martā nosauc šo pašu lietu valsts pārvaldes budžetam, COTS ir gatavs komerciāls programmnodrošinājums, ko var iegādāties un lietot bez būtiskas pielāgošanas, bet SaaS ir lietotne, kas pieejama internetā kā abonējams pakalpojums. Tās ir definīcijas plānošanai, ne pienākums privātam uzņēmumam, un mēs tās šeit ņemam kā vārdus, kuri jau ir nosaukti, ne kā likumu, kurš Jums uzliek VARAM saskaņojumu.
Pasūtījuma programmatūra ir sistēma, kuru raksta Jūsu procesam, un tajās pašās vadlīnijās specializētā programmatūra ir individuāli izstrādāta programmatūra konkrētas iestādes vai nozares vajadzībām. Mēs to saucam arī par pielāgotu sistēmu, pakalpojuma lapā par nestandarta sistēmu un virsrakstā par pasūtījuma programmatūru, un tie nav trīs produkti, bet viens darbs: kods, kurš sākas no Jūsu procesa, ne no ražotāja pieņēmuma par to, kas ir klients, pasūtījums vai rēķins, tāpēc atšķirība nav “labāks” pret “sliktāks”, bet tas, kurš pēc tam drīkst šo pieņēmumu mainīt.
Gatavais produkts nav izgāzusies pasūtījuma būve, un pasūtījuma būve nav labāks CRM, jo WooCommerce ir gatavs e-komercijas produkts, Moodle ir gatava mācību platforma, WordPress ir gatava satura platforma, un mēs visus trīs pārdodam kā ieviešanu, ne kā slēptu būvi zem cita nosaukuma. Laravel nav produkts šajā nozīmē: tas ir ietvars, uz kura mēs rakstām pasūtījuma sistēmas kopš versijas 4.0 2013.gadā, un tas nedod katalogu, grozu vai CRM, kamēr kāds tos nav uzrakstījis, tāpēc sajaukt ietvaru ar produktu nozīmē iedomāties, ka “uz Laravel” jau ir atbilde, lai gan tas ir tikai veids, kā atbildi uzrakstīt.
Trešā lieta, kuru šajā vietā parasti sajauc, ir abonements pret īpašumu, jo SaaS nozīmē, ka Jūs maksājat par lietošanu un datus tur piegādātājs, beztermiņa licence nozīmē, ka Jūs esat samaksājuši par tiesībām lietot versiju un atjauninājumi bieži ir atsevišķa rinda, bet pasūtījuma kods, kuru mēs nododam, nozīmē, ka avota kods, dokumentācija un infrastruktūras konfigurācija ir Jūsu. Nevienā no šīm rindām nav automātiskas uzvaras, ir tikai skaidrība, ko Jūs pērkat, jo pretējā gadījumā pēc gada Jūs strīdaties par to, vai “sistēma ir mūsējā”, kad patiesībā ir abonements, kuru var pārtraukt.
Tests, ar kuru mēs šo izvēli izdarām
Tests nav “vai mums patīk šis ekrāns”, bet tas, vai process, kuru Jūs nedrīkstat atdot konkurentam, ietilpst rīkā, kuru konkurents var nopirkt tajā pašā veikalā: ja ietilpst, rīks ir pareizā atbilde, jo tas būs lētāk un to uzturēs kāds, kura vienīgais darbs ir šis rīks, bet, ja neietilpst, jo cenu tabula, pasūtījuma apstiprinājums vai piegādes noteikumi ir tas, ar ko Jūs atšķiraties, tad gatavais produkts kļūst par kompromisu, un kompromiss šeit nozīmē, ka process sāk dzīvot Excel blakus sistēmai.
Otrā puse tam pašam testam ir pārāk bieži aizmirsta, jo vajadzības biežāk ir kopīgas, nekā unikālas, un pasta programmu nebūvē, grāmatvedību, kura jau dara to, ko prasa likums, nebūvē, un standarta pārdošanas piltuvi, kurā darījums ir darījums, arī nebūvē. Iestādes, kuras savu naudu tērē pēc rakstītiem kritērijiem, šo pašu formu ir nosaucušas citādi: vispirms jautā, vai tirgū jau ir lieta, un būvē tad, kad pieejamie produkti kodolu nesedz vai kad lietu vajag pārvaldīt pašiem, un tas nav Latvijas privātā uzņēmuma pienākums, un mēs to nepārvēršam par tādu, bet tā ir tā pati forma, ar kuru mēs sakām nē būvei, kuru var nopirkt.
Trešā kļūda ir produkta pārbūve, līdz tas vairs nav produkts, jo konfigurācija paliek atbalstītajās robežās (lauki, lomas, plūsmas, kuras ražotājs ir paredzējis), bet pielāgošana, kura pārraksta kodolu, lai process “beidzot derētu”, tērē tieši tās priekšrocības, kuru dēļ produktu pirka: atjauninājumus, dokumentāciju, to, ka kļūdu atrod kāds cits. Mēs to esam redzējuši Moodle ieviešanās, kur vispirms pārbaudām, vai spraudnis jau pastāv, un tikai tad rakstām savu, un WordPress vietnēs, kur gatavu tēmu neliekam, jo tā ienes desmitiem funkciju, kuras Jums nav vajadzīgas un kuras kļūst par drošības risku, tāpēc produkts ar svešu kodolu nav pasūtījuma sistēma, bet produkts, kuram Jūs esat izņēmuši ražotāja kodolu.
Mēs šo testu izdarām atklāšanas darbnīcā, ne piedāvājuma slaidā, jo slaidā vienmēr uzvar būve, kura izskatās pēc rūpēm par Jums, bet darbnīcā uzvar process, kuru var nosaukt. Ja pēc divām dienām izrādās, ka process ietilpst gatavā rīkā, mēs to sakām, arī tad, ja tas nozīmē, ka šīs nedēļas darījums nav mūsu nestandarta sistēma, jo raksts, kurš vienmēr beidzas ar “būvēsim Jums savu”, nav tests, bet piedāvājums, kurš slēpjas aiz jautājuma.
Kad gatavais produkts ir pareizā atbilde
Gatavais produkts ir pareizā atbilde tur, kur process jau ir nosaukts nozarē un Jūs neesat tie, kuri šo nosaukumu izgudroja, jo e-pasts, grāmatvedība, kas izraksta rēķinu tā, kā prasa likums, standarta pārdošanas CRM, mācību platforma, kura reģistrē kursu un izpildi, un mazs veikals ar vienu cenu un vienu noliktavu ir vietas, kur būve nedod neko tādu, par ko būtu vērts maksāt starpību starp licenci un sprintu. Mēs šīs rindas nepārdodam kā “pagaidu risinājumu, līdz būsiet gatavi īstajai sistēmai”, jo tās ir īstās sistēmas šiem procesiem.
Mēs šos produktus arī pārdodam, un tas nav slēpts solījums, ka pēc gada nāks būve: WordPress paliek satura platforma ar tēmu, kuru rakstām mēs, ne ar gatavu tēmu no veikala; mazam veikalam ar standarta procesiem mēs paši sakām WooCommerce; Moodle paliek mācību platforma, kuru konfigurējam, migrējam un noformējam, ne izgudrojam no jauna. Cenas šīm rindām stāv pakalpojumu lapās un vienā vietā zemāk šajā rakstā, kur vajag parādīt, ka pasūtījuma sākuma cena nav automātiski dārgākā rinda, un šeit pietiek pateikt, ka produkts paliek produkts.
Sekas, ja šajā vietā tomēr pasūtāt būvi, ir nevis “labāka kontrole”, bet uzturēšana, kuru Jūs vairs nedalāt ar tūkstošiem citu, jo pasta programmas drošības ielāpu kāds izlaiž visiem, bet savas pasta programmas ielāpu izlaižat Jūs, un tas izklausās pēc brīvības, kamēr nav otrās nakts, kurā jālabo tas, ko ražotājs jau ir salabojis savā produktā. Mēs šo brīvību pārdodam tur, kur process to pelna, ne tur, kur pietiek ar licenci, jo pretējā gadījumā mēs Jums pārdodam darbu, kuru pēc gada Jūs ienīdīsiet kā dārgu dublikātu.
Tāpēc godīgākā lieta, ko varam pateikt pirms jebkura nestandarta cenu aprēķina, ir saraksts ar produktiem, kurus mēs Jums ieteiktu tā vietā: ja process ir mācības, sāciet ar Moodle, ja process ir saturs, sāciet ar WordPress, ja process ir mazs veikals, sāciet ar WooCommerce, un, ja process ir rēķini un likumā noteiktā uzskaite, sāciet ar grāmatvedību, kura Jums jau ir, un tikai tad jautājiet, vai kaut kam no tā ir jākļūst par savu sistēmu. Šis saraksts nav partnerlīgums, tas ir tests, kuru mēs lietojam pret sevi.
Kad pasūtījuma programmatūra ir pamatota
Pasūtījuma programmatūra ir pamatota tad, kad process ir Jūsu konkurētspējas daļa vai gatavie risinājumi prasa pārāk daudz kompromisu, un process var palikt precei pakārtots un tomēr būt šī testa daļa, jo tests ir kompromisu skaits, ne tas, vai Jūs pārdodat programmatūru. Ja gatavais produkts sāk prasīt, lai Jūs kļūstat par vidējo klientu, un vidējais klients nav Jūsu konkurētspēja, būve beidzot ir tests, kuru process ir izturējis, ne vēlme pēc sava ekrāna.
Integrācija šeit nav arguments pati par sevi, jo produktiem arī ir saskarnes, un mēs tās pieslēdzam, un arguments sākas tikai tad, kad saskarne nav pietiekama un process prasa, lai patiesība par atlikumu, cenu vai statusu dzīvotu vienā vietā, kuru Jūs kontrolējat. Sadales tīkla karšu portāls, kuru esam būvējuši uz Laravel un Leaflet, rāda atslēgumus, brīvo jaudu un pieslēguma maksu, un tas nav “karte plus spraudnis”, jo maksa un jauda ir operatora process, ne karšu produkta lauks; Elektrum portālā SSO sesija pievienojas katram pieprasījumam, pirms Vue konfigurators zīmē, un tas nav “enerģētikas tēma WordPress”, jo sesija ir pakalpojuma daļa, ne dekorācija.
Krāsa, logo un izvēlnes kārtojums nav šis tests, jo to var izdarīt produktā, un mēs to izdarām produktā: Moodle tēma ar Jūsu paleti, WordPress tēma bez liekā, WooCommerce veikals, kurš izskatās pēc Jums. Ja vienīgais, ko nevar izdarīt gatavajā rīkā, ir “lai izskatās pēc mums”, Jūs neesat nonākuši līdz pasūtījuma programmatūrai, bet līdz tēmai, un sajaukt šīs divas lietas nozīmē maksāt par būvi tur, kur pietiek ar dizainu, un pēc tam brīnīties, kāpēc uzturēšana ir dārga sistēmai, kuras vienīgā atšķirība ir krāsa.
Mēs arī nesakām, ka katra nozare automātiski prasa savu platformu, jo nozares vārds nav tests, un tests ir, vai šīs nozares process Jūsu uzņēmumā ir tas pats, ko ražotājs jau ir ielicis paketē, vai tas ir Jūsu veids, kā nozare strādā, un šo veidu nedrīkst nopirkt blakus. Ja var nopirkt, pērciet; ja nevar, tad runa ir par pielāgotu biznesa sistēmu, un tikai tad ir vērts runāt par atklāšanas darbnīcu, ne par tēmu.
Trešais ceļš: produkts ar mūsu kodu virsū
Starp gatavo produktu un būvi no nulles ir trešais ceļš, kuru mēs arī pārdodam un kuru salīdzinājumi visbiežāk izlaiž: produkts paliek produkts, un virsū rakstām to, ko produkts nedara, un tas nav “nedaudz pasūtījuma programmatūras”, bet lēmums atstāt kodolu tur, kur to uztur ražotājs, un rakstīt tikai to slāni, kurš ir Jūsu. Sadales tīkla pakalpojumu portāls stāv uz October CMS, un kalkulatori, kalendāri un pieteikums par bojājumu ir darbs uz produkta, ne jauns satura dzinējs; Moodle ieviešanā vispirms pārbaudām, vai vērtēšanas vai atskaites spraudnis jau pastāv, un tikai tad rakstām savu, jo pretējā gadījumā mēs Jums pārdodam dublikātu.
Ja jautājums ir katalogs, cenas, pasūtījums un piegāde, tas ir veikala tests, un tas jau ir uzrakstīts rakstā par WooCommerce vai Laravel izvēli, tāpēc šeit to nepārrakstām un nepārvēršam par nestandarta sistēmas noklusējumu. Ja jautājums ir par CRM, ERP, iekšējo paneli vai nozares procesu, palieciet šeit, jo veikals ir viens gadījums no tā paša testa, ne visas izvēles saturs.
WordPress pusē trešais ceļš izskatās pēc atteikuma, jo gatavas tēmas mēs neliekam, tās ienes funkcijas, kuras kļūst par drošības risku, un būvējam tīru tēmu tikai ar to, kas vajadzīgs, un tas joprojām ir produkts: redaktors raksta WordPress redaktorā, ne mūsu izgudrotajā, un atjauninājumi nāk no WordPress, ne no mūsu laidiena vien. Atšķirība starp šo un pasūtījuma sistēmu ir tā, ka satura process ietilpst produktā, bet tēmas process neietilpst ThemeForest tēmā, un sajaukt tos nozīmē vai nu ielikt svešu tēmu un pēc tam brīnīties par spraudņiem, vai arī būvēt savu CMS saturam, kuram CMS jau pastāv.
Šī robeža ir arī vieta, kur mēs sakām nē “nelielai pārbūvei”, kura pēc trešā mēneša ir kodols, jo, ja pielāgojumu kļūst vairāk par konfigurāciju, ja katrs atjauninājums prasa mūsu kodu vispirms, ja ražotāja lauks vairs nav patiesība, Jūs vairs neesat uz trešā ceļa. Jūs esat uz būves, kura slēpjas aiz produkta nosaukuma, un tad godīgāk ir nosaukt būvi un rēķināt to kā būvi, jo pretējā gadījumā Jūs maksājat par produktu, kuru vairs nevar atjaunināt, un par sistēmu, kuru vēl nevar pārņemt.
Nauda un laiks ir forma, ne cenrādis
Pasūtījuma sistēma pie mums sākas no €8 000, un pilns cikls parasti aizņem no 12 līdz 32 nedēļām, un tas ir “sākot no”, ne rēķins, un 12 nedēļas nav tie paši pirmie trīs mēneši, kuros mēs solām lietojamu MVP: sākuma termiņš ir īsākā būve, MVP ir solis, pēc kura sistēmu jau lieto, un 32 nedēļas ir lielāka darba augšējā robeža, kura iekļaujas arī tajā, ko vispārīgajā FAQ saucam par sešiem līdz astoņiem mēnešiem lielai pielāgotai sistēmai. Laravel lapa sākas no tiem pašiem €8 000 un 6–24 nedēļām, un tā nav lētāka pasūtījuma programmatūra: tā ir lapa cilvēkam, kurš jau zina, ka darbs ir Laravel, ne tests, vai darbs vispār ir būve.
Šie skaitļi nedrīkst kļūt par teikumu “pasūtījuma programmatūra ir dārgākā izvēle”, jo Moodle ieviešana sākas no €15 000, veikala Pro versija maksā €9 500, un abas ir virs pasūtījuma sākuma cenas, jo viena ir liela produkta ieviešana, otra ir veikals ar noliktavu un B2B cenām. Salīdzināt “sākot no €8 000” ar Moodle “sākot no” kā “būve pret produktu” ir nepareiza aritmētika, jo salīdzināt var tikai viena un tā paša procesa divus ceļus, un pat tad abas puses ir sākuma cenas, ne kopsummas; lielākiem nestandarta darbiem rēķinām pēc laika un materiāliem ar nedēļas griestiem, jo fiksēta cena tur parasti nozīmē uzcenojumu riskam vai strīdu par apjomu, un stundas likme ir €50.
Abonements pret būvi arī nav formula, kurā pēc N gadiem viena puse automātiski uzvar, un VARAM vadlīnijas valsts plānošanai nosauc to, ko mēs redzam arī privātos līgumos: SaaS maksa var kāpt ar lietotāju skaitu vai indeksāciju, integrācijas paliek Jūsu izmaksas, un piegādātāja maiņai vajag izejas plānu, jo dati stāv pie viņa. Tas nav procents no būves, kuru mēs šeit citētu, jo vadlīniju zemsvītras piezīme ved uz piegādātāju blogiem, un tādus skaitļus mēs nerakstām, bet forma paliek: abonements ir rinda katru gadu, būve ir sākuma cena plus uzturēšana, un neviens no tiem nav bez rindas.
Datu akts, kas Savienībā piemērojams no 2025. gada 12. septembra — and the same space in the other four: "kas 2026.gada martā" → "kas 2026. gada martā"; "kopš versijas 4.0 2013.gadā" → "kopš versijas 4.0 2013. gadā"; "regulas 20.pants" → "regulas 20. pants" in body and again in faq[3].a, palīdz iznest iznesamos datus no mākoņa pakalpojuma un aizliedz piegādātājam likt šķēršļus maiņai, bet funkcionālo ekvivalenci tas prasa infrastruktūras pakalpojumam, ne CRM, kuru Jūs vienkārši “pārnesat”, un regula 2023/2854 nesola, ka process pārcelsies kopā ar failu. Vispārīgās datu aizsardzības regulas 20.pants pārnes personas datus, kurus subjekts ir sniedzis, ne lietotni, ne Jūsu konfigurāciju, ne biznesa noteikumus, tāpēc, ja gribat sistēmu, kuru varat pārcelt pie cita izstrādātāja, tas ir avota kods, kuru mēs nododam, ne eksports no sveša paneļa, un šī ir arī tā vieta, kur beidzas šī sadaļa, jo nākamais teikums jau būtu cenrādis, kura mums šim jautājumam nav.
Ko mēs nesakām, kad runājam par pasūtījuma programmatūru
Mēs nesakām, ka sava sistēma vienmēr ir gudrāka, ka gatavais produkts ir tiem, kuri “vēl nav izauguši”, vai ka pēc trim gadiem būve noteikti ir atmaksājusies, jo tāda līkne bez Jūsu procesa ir izdomājums. Raksts, kurš pēc godīga sākuma tomēr nonāk pie tā, ka jāpērk būve, ir aizgājis par tālu, un mēs to esam redzējuši pietiekami bieži, lai šeit apstātos, jo godīgums ir ierobežojums un īss tests ir mērķis.
Mēs arī nesakām, ka Laravel ir atbilde uz gatavā produkta jautājumu, jo Laravel ir veids, kā mēs rakstām, kad tests jau ir devis būvi, un pārdot ietvaru cilvēkam, kuram vajag Moodle, nozīmē pārdot āmuru cilvēkam, kuram vajag plauktu. Mūsu Laravel lapa sākas no €8 000 un runā par API, rindām un testiem, bet šis raksts runā par to, vai Jums vispār vajag šo lapu, un sajaukt tās nozīmē, ka Jūs izvēlaties instrumentu, pirms esat izvēlējušies darbu.
Mēs nesakām arī to, ka atklāšanas darbnīca ir slēpts veids, kā Jūs ievilināt būvē, jo darbnīcas rezultāts ir plāns, kurš paliek noderīgs arī tad, ja izlemjat mūs neizmantot, un dažkārt plāns saka: ņemiet produktu, kuru jau esat nosaukuši, un mēs to ieviesīsim, vai arī ieviesīs kāds cits. Ja šis teikums Jums izklausās pēc zaudēta darījuma, tas ir tāpēc, ka tas ir zaudēts darījums, un mēs labāk zaudējam būvi, kurā būtu jāuzraksta vēl viens CRM, nekā iegūstam klientu, kurš pēc gada jautā, kāpēc viņš uztur sistēmu, kuru varēja abonēt.
Valsts iepirkumam šis tests nedarbojas tāpat kā privātai firmai bez pielāgošanas, jo valsts plānošanā VARAM IKT vadlīnijas prasa izvērtēt, vai tirgū jau ir gatavs risinājums, un VIRSIS ir resursu reģistrs, ne šis tests, un tas pieder iepirkumam, ne šim teikumam, bet privātā pusē pieder Jūsu process un mūsu cenrādis. Abas puses var nonākt pie tās pašas atbildes, un tās nenonāk pie tās tāpēc, ka viena būtu otras likums.
Kā šo lēmumu pieņem pie mums
Darbs sākas ar divu līdz triju dienu atklāšanas darbnīcu, kurā kopā ar Jūsu komandu izrunājam procesus, lietotāju lomas, riskus un MVP apjomu, un tas nav slaidu rīts, bet darbs, pēc kura mēs varam pateikt, vai process ietilpst gatavā rīkā, vai tas prasa trešo ceļu, vai tas ir būve. Ja atbilde ir produkts, darbnīca ir atmaksājusies ar šo teikumu; ja atbilde ir būve, nākamais solis nav kods.
Pirms produkcijas koda mēs divās līdz trijās nedēļās sagatavojam klikšķināmu prototipu, jo tajā domas mainīt ir lētāk nekā gatavā sistēmā, un prototips nav “lai būtu, ko rādīt valdei”, bet vieta, kur Jūs redzat, ka cenu tabula, kuru vakar nosaucāt, patiesībā ir cita tabula, un kur šī atklāsme maksā dienas, ne mēnešus. Tikai pēc tam sākas izstrāde: pirmajos trīs mēnešos uzbūvējam MVP, ko var reāli lietot, un tālāk paplašinām iteratīvi, divu nedēļu sprintos ar demonstrāciju pēc katra.
Beigās Jūs saņemat avota kodu, dokumentāciju un infrastruktūras konfigurāciju un varat to pārcelt pie cita izstrādātāja, un tas nav solījums, ka pārcelšana būs patīkama, bet solījums, ka Jūs neesat piesaistīti mums. Lielākos projektos paliekam pie laika un materiāliem ar nedēļas griestiem, un MVP robežu tomēr fiksējam, jo pretējā gadījumā “agile” kļūst par vārdu, aiz kura pazūd apjoms, un, ja pēc darbnīcas Jūs ejat citu ceļu, plāns paliek Jums, kā esam uzrakstījuši pakalpojuma lapā, un šis raksts to nemaina.
Pirms rakstāt mums, uzrakstiet procesu vienā lappusē bez rīka nosaukuma un atzīmējiet, kuras rindas Jūs nedrīkstat atdot svešam laidienam: ja lappuse ir tukša vai tajā ir tikai “lai būtu sava sistēma”, Jums vajag produktu, un mēs to arī pateiksim, bet, ja lappusē ir process, kuru konkurents nevar nopirkt kā gatavu rīku, tad ir vērts runāt par būvi. Uzrakstiet mums, ja gribat, lai mēs šo lappusi izlasām kopā ar Jums un pasakām, kura puse Jums pieder, arī tad, ja atbilde ir ņemt produktu, kuru Jūs jau esat nosaukuši.
Bieži uzdotie jautājumi.
Kā saprast, vai man vajag pasūtījuma programmatūru?
Ja Jūsu process ietilpst gatavā rīkā, ņemiet gatavo rīku, tas būs lētāk. Pasūtījuma programmatūra ir pamatota tad, kad process ir Jūsu konkurētspējas daļa vai gatavie risinājumi prasa pārāk daudz kompromisu. Uzrakstiet procesu vienā lappusē bez rīka nosaukuma un atzīmējiet, kuras rindas Jūs nedrīkstat atdot svešam laidienam. Ja paliek tikai “lai būtu sava sistēma”, Jums vajag produktu, ne būvi.
Vai gatavais CRM vai ERP ir sliktāks par savu sistēmu?
Nē. Gatavais produkts nav izgāzusies būve, un pasūtījuma būve nav labāks CRM. WooCommerce, Moodle un WordPress mēs paši pārdodam kā produktu ieviešanu, ne kā slēptu būvi. Sava sistēma ir pamatota tad, kad process ir Jūsu konkurētspējas daļa vai gatavie risinājumi prasa pārāk daudz kompromisu, ne tad, kad gribat citu krāsu uz tā paša procesa.
Vai pasūtījuma sākuma cena nozīmē, ka būve ir dārgāka par produktu?
Nē. Nestandarta sistēma sākas no €8 000, un tas ir sākot no, ne rēķins. Moodle ieviešana sākas no €15 000, veikala Pro versija maksā €9 500, un abas ir virs šīs sākuma cenas, tāpēc pasūtījuma sākuma cena nav dārgākā rinda cenrādī. Lielākiem nestandarta darbiem strādājam pēc laika un materiāliem ar nedēļas griestiem, un stundas likme ir €50.
Kam pieder kods pēc pasūtījuma būves?
Jums. Avota kods, dokumentācija un infrastruktūras konfigurācija tiek nodoti, un Jūs varat to pārcelt pie cita izstrādātāja. Datu akts palīdz iznest iznesamos datus no mākoņa pakalpojuma, bet nepārbūvē procesu citā CRM. Vispārīgās datu aizsardzības regulas 20.pants pārnes personas datus, kurus subjekts ir sniedzis, ne lietotni.
Vai var sākt ar gatavu produktu un vēlāk pāriet uz savu sistēmu?
Jā, un bieži tas ir pareizais sākums, ja process vēl nav nosaukts. Trešais ceļš ir produkts ar mūsu kodu virsū, kamēr kodols paliek ražotāja rokās. Ja pielāgojumu kļūst vairāk par konfigurāciju, godīgāk ir nosaukt būvi un rēķināt to kā būvi, ne slēpt to aiz produkta nosaukuma.
Kad gatavais risinājums vienkārši neder. Būvējam no nulles — CRM, ERP, multi-tenant SaaS vai vadības panelis uz Laravel, Filament un React, Vue, Livewire.