Cena custom CMS-a ne može pouzdano da se odredi samo na osnovu broja stranica ili izgleda administracije. Dva sistema mogu imati sličan interfejs, a potpuno različit obim razvoja: jedan služi za unos tekstova i slika, dok drugi upravlja više sajtova, različitim tipovima sadržaja, odobravanjima, korisničkim pravima, integracijama i složenim pravilima prikaza.
Zato je korisnije posmatrati budžet kroz komponente projekta, a ne kroz jednu univerzalnu cenu. Ako se u ranoj fazi jasno odvoje funkcionalni obim, tehnički rizici i buduće potrebe, ponude postaju uporedivije, a verovatnoća naknadnih izmena i neplaniranih troškova je manja. Za razumevanje šireg pitanja kada je sopstveni sistem opravdan, koristan je i vodič Custom CMS: kada firmi zaista treba sopstveni sistem za sadržaj.
Od čega se zapravo sastoji cena custom CMS-a
Razvoj se najčešće može posmatrati kroz nekoliko budžetskih celina. One se prepliću, ali svaka nosi drugačije rizike i zahteva drugačije odluke:
- analiza potreba i modelovanje sadržaja;
- UX i dizajn administracije i javnog dela sistema;
- frontend i backend razvoj;
- korisničke uloge, dozvole i tokovi odobravanja;
- integracije sa drugim servisima;
- migracija postojećeg sadržaja;
- testiranje, bezbednost i puštanje u rad;
- održavanje, podrška i dalji razvoj.
Najčešća greška je da se budžet formira samo prema delu koji je vidljiv na ekranu. Administracija može izgledati jednostavno, ali iza jednog polja mogu stajati validacije, veze sa drugim entitetima, različite dozvole, API pravila, pretraga i zahtevi za kompatibilnost sa postojećim sistemima.
1. Obim i struktura sadržaja
Prvo pitanje nije koliko će stranica imati sajt, već kojim vrstama sadržaja sistem treba da upravlja. To mogu biti obične stranice, vesti, autori, lokacije, proizvodi, reference, dokumenti, kategorije, događaji ili međusobno povezani zapisi.
Za svaki tip sadržaja treba definisati polja, obaveznost, odnose sa drugim zapisima, način prikaza i pravila izmene. Na primer, „referenca” može sadržati naslov, opis i sliku, ali i klijenta, industriju, galeriju, povezane usluge, rezultate, SEO podatke i različite prikaze na više delova sajta. Što su ti odnosi složeniji, to raste obim i modelovanja i razvoja.
Šta treba popisati pre procene
- koji tipovi sadržaja postoje;
- koja polja su obavezna, a koja opciona;
- koji sadržaji se međusobno povezuju;
- da li se isti sadržaj prikazuje na više mesta;
- da li postoje više jezika, regiona ili brendova;
- ko može da kreira, menja, objavljuje ili briše zapis;
- da li se čuva istorija izmena i vraća prethodna verzija.
Ovaj popis je često vredniji od opisa poput „potrebna nam je fleksibilna administracija”, jer omogućava da se procenjuje stvarni rad, a ne neodređena želja.
2. Urednički tokovi, uloge i dozvole
Jedan urednik koji samostalno objavljuje sadržaj ima znatno jednostavniji proces od organizacije u kojoj autori pripremaju tekst, urednici ga proveravaju, pravna služba odobrava, a administrator upravlja pravima pristupa. Svaki dodatni korak može uticati na model podataka, interfejs, obaveštenja, istoriju promena i testiranje.
Potrebno je definisati da li korisnici imaju pristup svim sadržajima ili samo određenim sekcijama, brendovima, jezicima i tržištima. Takođe treba razjasniti da li se brisanje vrši odmah, da li postoji arhiva i da li je potrebno evidentirati ko je i kada promenio podatak.
Previše jednostavan sistem može dovesti do grešaka i ručne kontrole van CMS-a. Previše detaljan sistem, sa pravilima koja nikome nisu potrebna, povećava cenu i otežava svakodnevni rad. Dobar obim je onaj koji podržava stvarni proces, bez simuliranja organizacione kompleksnosti koja ne postoji.
3. Integracije najčešće menjaju procenu
Integracija nije samo dodavanje jednog dugmeta ili povezivanje dva URL-a. Potrebno je utvrditi koji sistem je izvor podataka, kako se podaci razmenjuju, koliko često, šta se dešava kada servis nije dostupan i kako se obrađuju greške.
Trošak mogu povećati integracije sa CRM-om, ERP-om, PIM-om, sistemom za newsletter, alatima za analitiku, servisima za plaćanje, pretragom, skladištem dokumenata ili eksternim API-jima. Posebno treba proveriti da li postojeća dokumentacija zaista opisuje sve potrebne slučajeve i da li je moguće dobiti testno okruženje.
Kod web shopa, sadržajni i commerce deo često dele proizvode, kategorije, filtre, korisnike ili promotivne komponente. Zato odvojena procena za CMS i odvojena procena za prodajni sistem ne mora prikazati stvarnu složenost. Više o toj odluci objašnjeno je u tekstu Custom CMS + web shop: zajednički content i commerce model.
4. Dizajn administracije i fleksibilnost stranica
Custom CMS ne mora da znači da se svaka stranica ručno sklapa od nule. Potrebno je odlučiti koji delovi imaju unapred definisanu strukturu, a gde marketing tim dobija fleksibilnost kroz blokove ili komponente.
Unapred definisani šabloni obično olakšavaju kontrolu sadržaja, dizajna i kvaliteta. Blokovi daju više slobode, ali zahtevaju pravila: koje kombinacije su dozvoljene, kako se komponente ponašaju na mobilnim uređajima, šta se dešava kada nedostaje slika i kako se sprečavaju nečitljive ili neusklađene stranice. Fleksibilnost zato nije besplatna karakteristika; ona zahteva dizajn sistema, validacije i testiranje.
Pri proceni treba razlikovati:
- jednostavne forme sa ograničenim brojem polja;
- stranice sastavljene od kontrolisanih blokova;
- potpuno slobodno slaganje komponenti;
- različite prikaze istog sadržaja za desktop, mobilni uređaj i druge kanale.
Detaljniji kriterijumi za ovu odluku nalaze se u tekstu Page builder blokovi: kako dati marketing timu fleksibilnost bez haosa.
5. Migracija sadržaja je posebna stavka
Ako se novi CMS uvodi na postojećem sajtu, migracija ne bi trebalo da bude skrivena u opštoj stavci „unos sadržaja”. Potrebno je utvrditi koliko zapisa postoji, u kom su formatu, da li su podaci konzistentni i da li se menjaju URL struktura, slike, dokumenti ili interne veze.
Automatska migracija može biti efikasna kada su podaci pravilno strukturirani. Ručna obrada može biti neophodna za stare tekstove, neujednačene galerije, duplikate i sadržaj koji zahteva uredničku proveru. Često je najbolji pristup kombinacija skripte, kontrole uzorka i ručne obrade izuzetaka.
U obim migracije treba uključiti i mapiranje starih i novih URL-ova, proveru nedostajućih medija, očuvanje relevantnih metapodataka i testiranje prebacivanja. Ako se ova tema otvori tek pred lansiranje, rok i budžet postaju teži za kontrolu.
6. SEO, performanse i pristupačnost nisu naknadni dodaci
CMS treba da omogući urednicima da kontrolišu elemente koji su deo objave sadržaja, ali konkretan obim zavisi od projekta. To mogu biti naslov stranice, meta opis, canonical URL, indeksiranje, preusmerenja, strukturirani podaci, alt tekstovi i pravila za deljenje na društvenim mrežama.
Važno je razlikovati mogućnost unosa od automatizacije. Jedno je omogućiti polje za SEO naslov, a drugo automatski generisati vrednosti, upozoravati na greške, upravljati konfliktima i primeniti pravila na više tipova sadržaja. Dodatna pravila povećavaju obim analize i testiranja. Za detaljniji pregled kontrola u sistemu pogledajte SEO kontrole u custom CMS-u: title, canonical, robots i schema.
Pristupačnost i performanse takođe utiču na arhitekturu, komponente i kriterijume prihvatanja. Ako su deo zahteva od početka, lakše ih je ugraditi u proces nego naknadno popravljati veliki broj šablona i sadržaja.
Kako napraviti realniji brief za ponudu
Najkorisniji brief ne mora biti dug, ali mora biti konkretan. Trebalo bi da sadrži najmanje:
- Cilj sistema: šta CMS treba da pojednostavi ili omogući.
- Tipove sadržaja: spisak entiteta, polja i odnosa.
- Korisnike: uloge, nivoe pristupa i proces odobravanja.
- Javni deo: glavne šablone, jezike, pretragu i filtre.
- Integracije: postojeće servise, API-je i odgovornost za pristupe.
- Migraciju: približan obim i kvalitet postojećih podataka.
- Operativne zahteve: hosting, backup, monitoring, bezbednost i podršku.
- Prioritete: šta mora biti u prvoj verziji, a šta može u kasnijoj fazi.
Na osnovu ovoga moguće je razdvojiti osnovni obim od opcija. Tako se ne dobija samo ukupna cifra, već i objašnjenje šta se dobija za određeni budžet i koje odluke najviše utiču na promenu procene.
Kako upoređivati ponude za custom CMS
Najniža ponuda nije nužno najpovoljnija, naročito ako ne objašnjava šta je izostavljeno. Pri poređenju proverite da li su u obim uključeni analiza, UX, razvoj, migracija, testiranje, obuka, dokumentacija i podrška nakon objave.
| Stavka za poređenje | Pitanje koje treba postaviti |
|---|---|
| Obim funkcija | Da li je jasno navedeno šta je uključeno, a šta nije? |
| Integracije | Da li su obuhvaćeni greške, autentikacija i testno okruženje? |
| Migracija | Da li se računa samo prenos ili i čišćenje i provera sadržaja? |
| QA i bezbednost | Koji scenariji se testiraju pre puštanja? |
| Održavanje | Šta se dešava nakon lansiranja i kako se obračunavaju izmene? |
| Vlasništvo i pristup | Ko dobija pristup kodu, podacima, dokumentaciji i infrastrukturi? |
Ovakvo poređenje je korisnije od direktnog poređenja ukupnih iznosa. Ponuda koja je na prvi pogled viša može imati širi obim, dok niža može pretpostavljati da klijent sam rešava migraciju, SEO podešavanja ili testiranje.
Kada je fazni razvoj bolja budžetska odluka
Ako nisu svi zahtevi jednako važni, custom CMS može da se planira po fazama. Prva faza može obuhvatiti ključne tipove sadržaja, osnovne uloge, najvažnije šablone i neophodne integracije. Kasnije se mogu dodati složeniji workflow-i, napredna automatizacija, dodatni brendovi ili nove uredničke komponente.
Fazni pristup ne znači da se arhitektura odlaže. Naprotiv, granice budućeg sistema treba uzeti u obzir od početka, kako prva verzija ne bi zatvorila prostor za razvoj. Istovremeno, ne treba unapred graditi funkcije za hipotetičke potrebe koje možda nikada neće postati stvarne.
Šta je koristan sledeći korak
Pre razgovora o budžetu pripremite spisak tipova sadržaja, uloga, integracija i postojećih podataka. Zatim razdvojite obavezne funkcije od onih koje bi bile korisne, ali nisu neophodne za prvu fazu. Takav materijal omogućava smisleniju procenu nego pitanje „koliko košta custom CMS?” bez dodatnog konteksta.
Ako tek procenjujete da li vam je potreban sopstveni sistem i kakav obim ima smisla, pogledajte stranicu Custom CMS. Ako je projekat bliži izradi kompletnog prezentacionog sajta nego razvoju posebne uredničke platforme, relevantna je i stranica izrada sajta. Cilj je da se izabere odgovarajuća arhitektura i obim, a ne da se plaća kompleksnost koja ne rešava stvarni problem.
