Gündəlik həyatdan sadə bir nümunə çəkək: Təsəvvür edin ki, yeni evinizi təmir etdirmək üçün bir ustaya yaxınlaşıb sadəcə "Mənə müasir və rahat bir mətbəx lazımdır" deyirsiniz. Nə dizayn layihəsi var, nə ölçülər, nə də istifadə olunacaq materialların siyahısı.
İki aydan sonra təmiri təhvil alanda görürsünüz ki, soyuducu üçün rozetka qoyulmayıb, qab-qacaq şkafı isə qapının açılmasına Mane olur. Usta isə haqlı olaraq deyir: "Siz mənə rahat olsun dediniz, rozetkanın harada olacağını demədiniz."
Hər gün onlarca şirkət ERP tətbiqində və ya proqram təminatı sifariş verərkən dəqiq bu xətanı təkrar edir.
Real Biznesdən İki Böyük Xəta Ssenarisi
Xəta 1: Şifahi Tələblər vә "Gedişatda Düzəldərik" Yanaşması
Şirkət rəhbərliyi proqramçı komandasına daxili satış və anbar modulunu yığmağı tapşırır. Bütün tələblər şifahi iclaslarda müzakirə olunur. Layihə bitdikdə məlum olur ki, proqram satış edir, lakin logistika modulunda mənfi stok (negative inventory) yaradır və maliyyə hesabatlarında faktiki maye dəyəri (COGS) təhrif olunur.
Səbəb: Biznes tələbi (BRD) və Funksional Tələblər Sənədi (FRS) yazılmayıb, kənar hallar (edge cases) nəzərə alınmayıb.
Xəta 2: İki Fərqli Dil — Biznes vә Proqramlaşdırma
Biznes meneceri proqramçıya deyir: "Mənə işçilərin məzuniyyət günlərini və əməkhaqqı qalıqlarını avtomatik hesablayan sistem lazımdır."
Proqramçı bunu öz anladığı kimi kodlaşdırır. Lakin Əmək Məcəlləsindəki xüsusi hesablama qaydaları və şirkətdaxili istisna halları nəzərə almadığı üçün sistem hər ay kadrlar və mühasibatlıq departamentində xaos yaradır.
Mühəndis Yanaşması: BRD, SRS və User Stories Niyə Həyati Vacibdir?
Proqram təminatının və ya ERP modulunun uğuru yazılan kodun həcmilə deyil, analiz və sənədləşmənin dəqiqliyi ilə ölçülür. Düzgün Tələblər Mühəndisliyi (Requirements Engineering) prosesində:
BRD (Business Requirements Document): Biznesin NƏ istədiyini və bu dəyişikliyin şirkətə HANSI maliyyə/əməliyyat dəyərini qatacağını müəyyən edir.
SRS / FRS (Software / Functional Requirements Specification): Biznes tələbini proqramçının anlayacağı texniki dilə çevirir. Məlumat bazasındakı cədvəllər, trigqerlər (Triggers), valydasiya qaydaları (Validation Rules) və funksiyalar bu sənəddə dənə-dənə təsvir olunur.
UAT (User Acceptance Testing) Ssenariləri: Kod yazılıb bitdikdən sonra sistem canlıya keçmədən əvvəl biznes tələblərinə 100% cavab verib-vermədiyi real ssenarilərlə test olunur.
Nəticə
Proqramçılara "Bizə yaxşı bir ERP lazımdır" demək, ustaya "Bizə gözəl bir ev tik" demək kimidir. Nəticənin fəlakət olmaması üçün biznes idarəçiləri ilə texniki komanda arasında peşəkar bir Biznes Analitik və ERP Arxitektor körpüsü olmalıdır.
Sənədləşməyə xərclənməyən 1 həftə, gələcəkdə sistemi yenidən yığmaq üçün xərclənən 6 aya və itirilmiş milyonlara bərabərdir.
22 Aug 2026
