# ERP joriy qilish: 8 bosqichli checklist - Canonical: https://blog.bahromnajmiddinov.uz/blog/erp-joriy-qilish-checklist - Author: Bahrom Najmiddinov - Published: 2026-09-20 - Odoo versions: 17.0, 18.0, 19.0 - Language: uz > **TL;DR** ERP loyihalari koʻpincha kod emas, qarorlar sabab muvaffaqiyatsiz boʻladi. Bu checklist yirik integratorlar ishlatadigan 8 bosqichli tartibni — discovery dan go-live va qoʻllab-quvvatlashgacha — kichik loyihalarga moslab beradi. Men koʻrgan muvaffaqiyatsiz ERP loyihalarining hech birida sabab “dasturchi kodni yomon yozdi” boʻlmagan. Sabab har doim boshqa joyda edi: kimdir qaror qabul qilmadi, kimdir eski bazadagi 4 000 ta dublikat mahsulotni yangi tizimga olib oʻtdi, kimdir “bu ham kerak edi-ku” deb loyihani toʻxtovsiz kengaytirdi. Shuning uchun yirik integratorlar dasturlash metodologiyasiga emas, **joriy qilish metodologiyasiga** pul sarflaydi. SAPʼda u SAP Activate, Oracleʼda Oracle Unified Method, Microsoftʼda Sure Step deb ataladi. Nomlar boshqa — skelet bitta. Quyida oʻsha skeletning amaliy koʻrinishi. Har bir bosqichda: nima qilinadi, nimaga eʼtibor beriladi va qayerda koʻpchilik qoqiladi. ## 1. Discovery — hozir nima bor? Bu bosqichda maqsad yechim taklif qilish emas. Maqsad — **mavjud holatni gapirmasdan tinglab, yozib olish** (AS-IS). **Nima qilinadi:** - Har bir boʻlimning real jarayoni kuzatiladi. Soʻrovnoma emas, kuzatuv: odam ekranda nimani bosadi, qaysi Excel faylni ochadi, kimga qoʻngʻiroq qiladi. - Har bir boʻlimdan bitta **key user** tayinlanadi — oʻz sohasi boʻyicha qaror qabul qila oladigan odam. - Ogʻriqli nuqtalar raqamga aylantiriladi. Oxirgi punkt eng muhimi. “Skladda tartib yoʻq” — bu shikoyat, oʻlchov emas. “Oyiga 40 soat qoʻlda inventarizatsiya, oxirgi 3 oyda 12 ta notoʻgʻri yuklash” — bu oʻlchov. Loyiha tugagach, muvaffaqiyatni aynan shu raqamlar bilan isbotlaysiz. **Chiqish hujjati:** loyiha doirasi (scope). Nima kiradi, nima kirmaydi — yozma ravishda. Keyinroq muqarrar ravishda paydo boʻladigan “bu ham kerak edi-ku” bahsini faqat shu hujjat yopadi. ## 2. Design — qanday boʻlishi kerak? AS-ISʼdan TO-BEʼga oʻtish. Va bu bosqichning yuragi — **Fit-Gap analiz**. Har bir talab ikkiga ajratiladi: - **Fit** — tizimning standart funksiyasi bilan qoplanadi. - **Gap** — qoplanmaydi. Gapʼning har biriga aniq qaror yoziladi: Qaror Qachon tanlanadi Jarayonni oʻzgartirish Talab odat boʻlgani uchun mavjud, biznes qiymati yoʻq Konfiguratsiya bilan yopish Standart sozlamalar yetarli Customization (kod) Talab kompaniyaning raqobat ustunligi yoki qonun talabi Keyingi fazaga qoldirish Hozir kerak emas, ammo unutilmasligi kerak ## Nega standartga yaqin turish kerak Bu — yirik implementorlarning eng qatʼiy qoidasi va koʻpincha mijozga eng yoqmaydigan qoidasi. Har bir ortiqcha customization — bir martalik xarajat emas, **obuna**. Siz uni bir marta yozasiz, keyin har bir versiya yangilanishida, har bir yangi modul qoʻshilganda va har bir xato tekshiruvida yana toʻlaysiz. 20 ta customization bilan chiqqan tizim 3 yildan keyin yangilanmay qoladi — chunki yangilanish narxi yangi loyiha narxiga tenglashadi. Amaliy mezon: agar talab “biz doim shunday qilganmiz” bilan asoslansa — jarayonni oʻzgartiring. Agar “mijozlarimiz aynan shuni talab qiladi” bilan asoslansa — kod yozing. ## 3. Build — konfiguratsiya, keyin development Tartib muhim: **avval sozlash, keyin kod.** Tajribamda talablarning katta qismi kodsiz, faqat toʻgʻri sozlash bilan yopiladi — shart sizning tizimni yetarlicha chuqur bilishingizda. **Texnik minimum:** - Uchta alohida muhit: **Development → Staging → Production**. Productionda tajriba qilish — yozilmagan qoidani buzish. - Butun kod Gitʼda. Mijoz serveridagi “faqat shu yerda bor” fayl — kelajakdagi falokat. - Migratsiya va maʼlumot skriptlari **idempotent** boʻlsin: ikki marta ishga tushirilsa ham natija bir xil. - Har bir oʻzgarish Stagingʻda sinalmaguncha Productionʼga chiqmaydi. ## 4. Data migration — eng koʻp vaqt yeydigan bosqich Loyiha rejasida bu bosqich odatda kam baholanadi. Amalda esa u koʻpincha butun loyihaning eng uzun qismi boʻlib chiqadi. **Bosqichlar:** 1. **Roʻyxat.** Nima koʻchiriladi: mahsulot katalogi, kontragentlar, sklad qoldigʻi, ochilish balansi, ochiq buyurtmalar, qarzdorlik. 2. **Tozalash.** Eski bazadagi axlat yangi tizimga oʻtmasligi kerak. 4 000 ta mahsulotning 1 200 tasi dublikat boʻlsa — ularni migratsiyadan **oldin** birlashtiring. Keyin emas. 3. **Sinov importi.** Kamida ikki marta, toʻliq hajmda, Staging muhitida. 4. **Solishtirish (reconciliation).** Har bir importdan keyin: jami sklad qoldigʻi, jami debitor/kreditor qarzdorlik, konto balanslari — eski tizim bilan tiyin-tiyingacha mos kelishi kerak. Agar 4-punkt bajarilmasa, siz xatoni goʻliveʼdan keyin, buxgalter hisobotni yopolmay qolganda topasiz. ## 5. UAT — mijoz qabul testi **User Acceptance Testing** — tizimni mijozning oʻzi tekshiradigan bosqich. Sizning ichki testingiz bu emas. **Qoidalar:** - Test stsenariylari real hujjatlar asosida yoziladi: oʻtgan oyning haqiqiy buyurtmasini oling va uni sotuv → yetkazib berish → invoys → toʻlov zanjiri boʻylab oʻtkazing. - Testni key userʼlar bajaradi. Siz faqat kuzatasiz va yozib borasiz. - Har bir topilgan xato roʻyxatga tushadi, masʼul va muddat belgilanadi, yopilguncha kuzatiladi. - **UAT rasman qabul qilinmaguncha go-live yoʻq.** Bu sizni ham, mijozni ham himoya qiladi. ## 6. Training — tizimni odamlar ishlatadi Texnik jihatdan mukammal tizim, agar kassir undan qoʻrqsa, ishlamaydi. - Oʻqitish **rollar boʻyicha** boʻlinadi: kassirga kassa kerak, buxgalterga hisobot. Hammaga hamma narsani koʻrsatish — vaqtni behuda sarflash. - Materiallar mijoz xodimlari tushunadigan tilda: qisqa videolar va 1–2 betlik amaliy yoʻriqnomalar. - Har bir boʻlimda 1–2 ta **champion** tayyorlanadi. Ular kundalik savollarning 80 foizini siz ishtirok etmasdan yopadi va qoʻllab-quvvatlash yukini keskin kamaytiradi. ## 7. Go-live — cutover Cutover — eski tizimdan yangisiga oʻtishning aniq soatlarga boʻlingan rejasi. **Sana tanlash.** Oy yoki chorak boshi qulay: buxgalteriya davri toza boshlanadi. Yuqori mavsum oʻrtasi — eng yomon variant. **Cutover rejasi soatlab yoziladi:** ```text 18:00 — eski tizimda yangi hujjat kiritish to'xtatiladi 19:00 — yakuniy qoldiq va balanslar olinadi 20:00 — ma'lumot importi boshlanadi 23:00 — solishtirish va tekshiruv 00:30 — GO / NO-GO qarori 08:00 — yangi tizimda ish boshlanadi ``` **Rollback rejasi.** Har bir cutover rejasida “agar ishlamasa nima qilamiz” bandi boʻlishi shart: qaysi nuqtaga qaytamiz, eski tizim qancha vaqt tirik turadi, qarorni kim qabul qiladi. Bu reja deyarli hech qachon ishlatilmaydi — ammo u boʻlmasa, tungi soat ikkida panika boshlanadi. ## 8. Hyper-care — birinchi 2–4 hafta Go-live loyihaning tugashi emas. Undan keyingi 2–4 hafta — kuchaytirilgan qoʻllab-quvvatlash rejimi: - Javob muddati odatdagidan qisqa. - Har kuni qisqa yigʻilish: bugun kim nimaga qoqildi? - Topilgan muammolar tezda tuzatiladi va yoʻriqnomalarga qaytariladi. Shu davr yakunlangandan keyingina loyiha odatiy support rejimiga topshiriladi. Topshirish ham rasmiy boʻlsin: nima ishlayapti, nima qoldi, keyingi faza nima. ## Xulosa Ushbu sakkiz bosqichda murakkab texnologiya yoʻq. Ularning hammasi — tartib-intizom haqida. Va aynan shuning uchun koʻpchilik ularni oʻtkazib yuboradi: Discovery “vaqtni yeydi”, Fit-Gap “keraksiz qogʻozbozlik”, UAT “biz oʻzimiz tekshirdik-ku” boʻlib tuyuladi. Har bir oʻtkazib yuborilgan bosqich esa go-live kunida qaytib keladi — faqat bir necha barobar qimmat narxda. Loyihalar texnik sabablarga koʻra kamdan-kam qulaydi. Koʻpincha sabab uchta: **hujjatsiz kengaygan scope, tozalanmagan maʼlumot va mijoz tomonida qaror qabul qiladigan odamning yoʻqligi.** Agar loyihani boshlashdan oldin shu uchtasini yopib olsangiz, qolgani texnika masalasi.