સૉફ્ટવેર ખરીદવું

કસ્ટમ સૉફ્ટવેર સામે રેડીમેડ: ખરેખર નિર્ણય કેવી રીતે લેવો

આ નિર્ણય મોટે ભાગે કિંમત પર લેવાય છે અને ફિટ પર પસ્તાવો થાય છે. એને બરાબર ચલાવવાની રીત આ છે, એ કિસ્સાઓ સહિત જ્યાં અમે લોકોને ન બનાવડાવવાનું કહીએ છીએ.

8 મિનિટનું વાંચન Plexowave

અમે કસ્ટમ સૉફ્ટવેર બનાવીએ છીએ, તેથી આગળ જે છે તેને એટલી જ શંકાથી લો જેટલી તેને લાયક છે. તોય એ સાચું છે કે અમને આ પ્રશ્ન પૂછતા મોટાભાગના વ્યવસાયોએ બનાવડાવવાને બદલે ખરીદવું જોઈએ, અને જેમણે બનાવડાવવું જોઈએ તેઓ સામાન્ય રીતે ફોન કરતાં પહેલાં જ કારણ જાણે છે — તેઓ બસ ઇચ્છે છે કે કોઈ ખાતરી કરે કે જે વસ્તુ તેમને મળતી નથી તે છે જ નહીં.

નિર્ણય સામાન્ય રીતે ખર્ચના રૂપમાં મૂકાય છે. એ માળખું ખોટું છે, કારણ કે બંને વિકલ્પોના ખર્ચનું સ્વરૂપ જુદું છે. પૅકેજ્ડ સૉફ્ટવેરનો ખર્ચ ઓછો, નિશ્ચિત અને આવર્તક છે અને ફિટ અનિશ્ચિત. કસ્ટમ નિર્માણનો ખર્ચ વધુ, અનિશ્ચિત અને એકવારનો છે અને ફિટ એ જ જે તમે નક્કી કરો. પહેલા આંકડાની પહેલા આંકડા સાથે સરખામણી લગભગ કશું કહેતી નથી.

એ ચાર પ્રશ્નો જે નિર્ણય કરી આપે છે

આ ક્રમમાં ચલાવો. જે પહેલો સ્પષ્ટ જવાબ આપે, સામાન્ય રીતે ત્યાં જ ચર્ચા પૂરી થાય છે.

  1. શું આ પ્રક્રિયા સ્પર્ધાત્મક લાભ છે, કે માત્ર જરૂરી છે?પેરોલ જરૂરી છે. અસાધારણ રીતે સારું પેરોલ ચલાવીને કોઈ ધંધો જીતતું નથી, તેથી એ ખરીદો. તમે કોઈ કામનો ખર્ચ કેવી રીતે કાઢો છો, કોઈ લોટને ખરીદદાર સાથે કેવી રીતે મેળવો છો, કે તમારાં મશીન કેવી રીતે શેડ્યુલ કરો છો — એ જ ખરેખર તમારી સ્પર્ધા હોઈ શકે, અને તેને બીજાના વર્કફ્લોમાં ઢાળવું એ જ તેના પર સ્પર્ધા કરવાનું બંધ કરવાની રીત છે.
  2. શું કોઈ પૅકેજ્ડ ઉત્પાદન તમારા ડેટા મૉડેલને વ્યક્ત કરી શકે?તમારી સ્ક્રીન નહીં — તમારું મૉડેલ. જો તમારા સ્ટૉકમાં બે એકમ હોય જે બંને સાચાં રહેવાં જોઈએ, જો માલ તમારો હોવા છતાં ભૌતિક રીતે બીજે હોય, જો કોઈ કામદારને એક જ મહિનામાં ત્રણ જુદી રીતે ચૂકવણી થતી હોય, તો એક જથ્થા ફીલ્ડ અને એક પગાર માળખાવાળી સિસ્ટમ એવી રીતે ખોટી હશે જ્યાં કૉન્ફિગરેશન પહોંચી જ શકતું નથી.
  3. કેટલાં પૅકેજ જોઈશે?એક સારું પૅકેજ મોટાભાગે કસ્ટમ નિર્માણ કરતાં સારું હોય છે. ચાર પૅકેજ અને તેમને જોડતી સ્પ્રેડશીટ લગભગ ક્યારેય નહીં — તમે ચાર ફિટ સમસ્યાઓ ખરીદી લીધી છે અને નામ આપ્યા વગર એક ઇન્ટિગ્રેશન પ્રોજેક્ટ બનાવી લીધો છે.
  4. ત્રણ વર્ષ પછી તેનો માલિક કોણ હશે?કસ્ટમ નિર્માણ માટે કોઈ જવાબદાર જોઈએ — ભલે તે આંતરિક ડેવલપર હોય, રિટેનર હોય, કે બીજો સ્ટુડિયો. જો પ્રામાણિક જવાબ 'કોઈ નહીં' હોય, તો તેના બદલે સપોર્ટ કરાર સાથેનું કંઈક ખરીદો. જાળવણી વગરનું કસ્ટમ સૉફ્ટવેર બીજી કોઈપણ વસ્તુ કરતાં ઝડપથી બોજ બની જાય છે.

બંને બાજુ એ ખર્ચ જે લોકો ચૂકી જાય છે

પૅકેજ્ડની બાજુએ, આવર્તક લાઇસન્સ દેખાતો ખર્ચ છે અને ભાગ્યે જ સૌથી મોટો. છુપા ખર્ચ છે પ્રતિ-વપરાશકર્તા કિંમત જે કર્મચારી સંખ્યા સાથે વધે છે, એ મૉડ્યુલ જે અલગ ઉત્પાદન નીકળે છે, ઇમ્પ્લિમેન્ટેશન પાર્ટનર, વાર્ષિક વધારો, અને એ કામ જે તમારી ટીમ સૉફ્ટવેર જે કરે છે અને તમને જે જોઈએ છે તે વચ્ચેનું અંતર પૂરવામાં કરે છે — જે કાયમી સ્ટાફ ખર્ચ છે અને સરખામણીમાં ક્યારેય દેખાતો નથી.

પૅકેજ્ડનો સૌથી મોટો ખર્ચ સામાન્ય રીતે એ જ છે જેની કિંમત કોઈ ગણતું નથી: એ પ્રક્રિયાઓ જે તમે સૉફ્ટવેરમાં બંધબેસવા બદલો છો. ક્યારેક એ લાભ છે, કારણ કે પૅકેજ્ડ પ્રક્રિયા તમારી કરતાં સારી છે. ક્યારેક તેનો અર્થ એ કે તમારા શ્રેષ્ઠ લોકો આખું અઠવાડિયું એવી ડેટા એન્ટ્રી કરે છે જે માત્ર સિસ્ટમને ખુશ રાખવા માટે છે.

કસ્ટમની બાજુએ, નિર્માણ દેખાતો ખર્ચ છે અને સામાન્ય રીતે તેનો અંદાજ પ્રામાણિકપણે મુકાય છે. જે ઓછું આંકવામાં આવે છે તે છે ડેટા માઇગ્રેશન, સમાંતર સંચાલન, અને બીજા વર્ષના ફેરફારો. માઇગ્રેશન લગભગ હંમેશાં દેખાય તેના કરતાં ખરાબ હોય છે, કારણ કે જૂના ડેટામાં દાયકા જૂના એવા અપવાદો છે જેને કોઈએ નોંધ્યા નથી. સમાંતર સંચાલન ન વૈકલ્પિક છે ન મફત — કોઈ મહિનાભર કામ બે વાર કરે છે. અને જે સૉફ્ટવેર બદલાઈ ન શકે તે તમે બદલી નાખશો, તેથી ફેરફારને નિષ્ફળતા ગણવાને બદલે તેનું બજેટ રાખો.

એ હાઇબ્રિડ જેનું સૂચન કોઈ કરતું નથી

વ્યવહારમાં આ ભાગ્યે જ બધું-કે-કશું નહીં હોય છે, અને સૌથી સારો જવાબ ઘણી વાર એ જ છે કે સામાન્ય વસ્તુ ખરીદો અને ભેદ પાડતી વસ્તુ બનાવડાવો. વૈધાનિક હિસાબના ચોપડા તરીકે પૅકેજ્ડ લેખા પ્રણાલી રાખો. એ સંચાલન પ્રણાલી બનાવડાવો જે તમારા ધંધાને જાણે છે, અને લેખામાં આપમેળે નોંધ કરાવો.

આ એટલા માટે કામ કરે છે કે તે સીમા સાચી જગ્યાએ મૂકે છે. લેખાના નિયમો બધા માટે સરખા છે અને કાયદાથી બદલાય છે; સંચાલનના નિયમો તમારા છે અને તમે નક્કી કરો ત્યારે બદલાય છે. એક જ સિસ્ટમ પાસે બંને કરાવવાનો પ્રયાસ જ બંનેનું સૌથી ખરાબ સંસ્કરણ પેદા કરે છે.

અમે ક્યારે લોકોને ખરીદવાનું કહીએ છીએ

એક પ્રમાણભૂત જરૂરિયાત જેનું બજાર પરિપક્વ છે. એકલ-એકમ વ્યવસાય માટે લેખા, ઈમેલ, પગારદાર સ્ટાફનું પેરોલ, દસ્તાવેજ સંગ્રહ, સાદું ઉત્પાદન વેચતી નાની ટીમ માટે સામાન્ય CRM. આ શ્રેણીઓમાં દાયકાઓથી હજારો ગ્રાહકો સામે ઘડાયેલાં ઉત્પાદનો છે. અમે બાર અઠવાડિયાંમાં તેમને હરાવી શકીએ નહીં અને બીજું કોઈ પણ નહીં.

અસ્પષ્ટ સમસ્યા. જો જરૂરિયાત એ લોકો સાથેની વાતચીતમાં ન ટકે જે તેનો ઉપયોગ કરશે, તો નિર્માણ એ ગૂંચવણનું મોંઘું સંસ્કરણ બનાવી દેશે. કંઈક સસ્તું ખરીદીને છ મહિના તેની સાથે કાઢવા એ જાણવાની વાજબી રીત છે કે તમને ખરેખર શું જોઈએ, અને ઘણી સસ્તી પણ.

બીજા વર્ષ માટે ન કોઈ જવાબદાર, ન બજેટ. જે નિર્માણને સંભાળનાર કોઈ નથી, તે બરાબર એ જ લેગસી સિસ્ટમમાં ફેરવાઈ જાય છે જેને બદલવા પ્રોજેક્ટ બન્યો હતો, ફક્ત હવે તે માત્ર તમારી પાસે છે.

જ્યારે બનાવડાવવું સ્પષ્ટપણે યોગ્ય છે

તમે પૅકેજ અજમાવ્યાં છે અને દરેક એક જ જગ્યાએ નિષ્ફળ ગયું. એ જગ્યા સામાન્ય રીતે તમારું ડેટા મૉડેલ છે, અને એ જ નિષ્ફળતાનું બિંદુ રહેશે, કારણ કે કૉન્ફિગરેશનથી એ એક જ વસ્તુ બદલાતી નથી.

સૉફ્ટવેર જ ઉત્પાદન છે, અથવા એ જ છે જેનો અનુભવ ગ્રાહક કરે છે. એવા પ્લેટફોર્મ પર કોઈ અલગ દેખાતું નથી જેનું સબ્સ્ક્રિપ્શન સ્પર્ધકો પણ લઈ શકે.

ઇન્ટિગ્રેશનનું કામ નિર્માણ કરતાં વધી જશે. જ્યારે ચાર સિસ્ટમે સંમત થવું પડે અને જોડવાનું કામ લોકો અને સ્પ્રેડશીટ કરે, ત્યારે તમે પહેલેથી જ કસ્ટમ સિસ્ટમની કિંમત ચૂકવી રહ્યા છો — ફક્ત સૉફ્ટવેરમાં નહીં, પગારમાં, અને સૉફ્ટવેર મળ્યા વગર.

અનુપાલન કે ડેટા રેસિડન્સી પૅકેજ્ડ વિકલ્પને ખરેખર અશક્ય બનાવી દે. આ દાવા જેટલું સામાન્ય નથી, તેથી ચકાસો કે એ ખરી અડચણ છે કે પસંદગી — પણ જ્યારે એ ખરી હોય, ત્યારે તે નિર્ણાયક છે.

પ્રતિબદ્ધ થતાં પહેલાં નિર્ણય કેવી રીતે ચકાસવો

  • એ ત્રણ બાબતો લખો જે તમારી વર્તમાન પ્રક્રિયા કરે છે અને જે તમને લાગે છે કે કોઈ પૅકેજ સંભાળતું નથી. પછી એક દિવસ ખરેખર પ્રયાસ કરો કે કોઈ એક પૅકેજ તે કરી આપે. મોટાભાગના વાંધા આમાં ટકતા નથી, અને જે ટકે છે તે જ તમારી ખરી જરૂરિયાતો છે.
  • કોઈપણ વિક્રેતા પાસે તમારા ચોક્કસ ક્ષેત્રમાં રેફરન્સ માગો, અને એ રેફરન્સને પૂછો કે તેમણે પોતાની કામ કરવાની રીતમાં શું બદલવું પડ્યું. એ જ જવાબ ફિટનું અંતર છે, એવી વ્યક્તિના મોંએ જેને તેને નાનું બતાવવામાં કોઈ લાભ નથી.
  • પૅકેજ્ડ વિકલ્પની કિંમત ત્રણ વર્ષ માટે ગણો — ઇમ્પ્લિમેન્ટેશન, વાર્ષિક વધારો અને અંતર પૂરવામાં જતા સ્ટાફ સમય સહિત — પહેલા વર્ષની લાઇસન્સ ફી પર નહીં.
  • નિર્માણ માટે એવી તબક્કાવાર યોજના પર ભાર મૂકો જ્યાં ત્રણ મહિનાની અંદર કંઈક વાસ્તવિક ઉત્પાદનમાં હોય. જો પહેલી ડિલિવરી નવમા મહિને હોય, તો જોખમ સંભાળાઈ રહ્યું નથી, માત્ર ટાળાઈ રહ્યું છે.

ટૂંકમાં

સામાન્ય વસ્તુ ખરીદો. જેના પર તમે સ્પર્ધા કરો છો તે બનાવડાવો, જો તેને સંભાળનાર કોઈ હોય. કોઈપણ પર — અમારા સહિત — શંકા કરો જે તમારું ડેટા મૉડેલ સમજ્યા વગર આ પ્રશ્નનો જવાબ આપી દે, કારણ કે જવાબ ખરેખર ત્યાં જ વસે છે.

પ્રશ્નો

સામાન્ય પ્રશ્નો.

શું કસ્ટમ સૉફ્ટવેર હંમેશાં મોંઘું હોય છે?

ત્રણ વર્ષમાં ઘણી વાર નહીં — પણ સરખામણીમાં ઇમ્પ્લિમેન્ટેશન, પ્રતિ-વપરાશકર્તા વધારો, અલગ વેચાતાં મૉડ્યુલ, અને અંતર પૂરવામાં જતો સ્ટાફ સમય સામેલ હોવો જોઈએ. પહેલા વર્ષે પૅકેજ્ડ વિકલ્પ લગભગ હંમેશાં સસ્તો હોય છે, અને જો ફિટ સારો હોય તો સસ્તો રહે છે.

કસ્ટમ નિર્માણમાં કેટલો સમય લાગે છે?

એક કેન્દ્રિત આંતરિક સિસ્ટમ સામાન્ય રીતે ઉત્પાદન સુધી આઠથી ચૌદ અઠવાડિયાં લે છે. બહુ-મૉડ્યુલ પ્લેટફોર્મ વધુ સમય લે છે અને તબક્કાવાર અપાવું જોઈએ, પહેલું મૉડ્યુલ ચાલુ હોય ત્યારે બીજું બનતું રહે. જો નવમા મહિના પહેલાં કશું ઉત્પાદનમાં ન પહોંચે, તો કારણ પૂછો.

શું અમે પૅકેજથી શરૂ કરીને પછી કસ્ટમ પર જઈ શકીએ?

હા, અને એ ઘણી વાર સમજદારીભર્યો રસ્તો છે. કંઈક પૅકેજ્ડ વાપરવાથી ઓછા ખર્ચે જરૂરિયાતો સ્પષ્ટ થાય છે. બચાવવાની એક જ વસ્તુ છે — તમારો ડેટા: ખાતરી કરો કે સિસ્ટમ પર નિર્ભર થતાં પહેલાં તમે તેને સંપૂર્ણપણે, દસ્તાવેજીકૃત ફોર્મેટમાં નિકાસ કરી શકો છો.

જો ડેવલપર ગાયબ થઈ જાય તો શું?

આ પૂછવા જેવો સાચો પ્રશ્ન છે અને જવાબ માળખાકીય હોવો જોઈએ, આશ્વાસન નહીં. રિપોઝિટરી તમારી છે, ડિપ્લોયમેન્ટ દસ્તાવેજીકૃત છે, સ્ટૅક વિચિત્ર નહીં પણ મુખ્યધારાનો છે, અને કોઈ રનટાઇમ લાઇસન્સ તમને બાંધતું નથી. આ ચાર બાબતો મળીને ખાતરી આપે છે કે બીજી ટીમ તેને સંભાળી શકે છે.

આ જ નિર્ણય પર કામ કરી રહ્યા છો?

ઉકેલને બદલે સમસ્યા જણાવો. જો જવાબ એવું ઉત્પાદન હોય જે તમે ખરીદી શકો, કે પછી કોઈ સૉફ્ટવેર જ નહીં, તો અમે એ જ કહીશું.

પ્રોજેક્ટ શરૂ કરો