فهم Business للتقنيين: من “كود ممتاز” إلى “أثر ملموس”

بقلم: د. أحمد السالمي

يخطئ كثير من التقنيين حين يظنون أن جودة الحل تُقاس بجمال الكود أو سرعة النظام أو تعقيد التكاملات. هذه عناصر مهمة، لكنها ليست المعيار النهائي. المعيار الذي يدفع عليه Business ليس “سطر كود”، بل نتيجة: قرار أسرع، تكلفة أقل، جودة أعلى، ورضا أكبر. وهنا تبدأ قيمة فهم Business للتقنيين: أن تتحول من منفّذ متطلبات إلى شريك قرار، ومن مطوّر شاشات إلى مهندس أثر.

في بيئات الـ ERP، والحوكمة، وإدارة العمليات، وإدارة التغيير، نرى سيناريو متكرر: شركة تشتري نظامًا قويًا، وتنفذ المشروع بأفضل الممارسات التقنية… ثم بعد أشهر تسمع العبارة المؤلمة: “طبقنا النظام وما تغيّر شيء.” السبب غالبًا ليس تقنيًا؛ السبب أن الحل بُني دون أن يُربط بوضوح بـ هدف تشغيلي، وألم حقيقي، ومؤشرات قياس تُثبت الأثر.

1) الدرس الأول: Business لا يشتري نظامًا… يشتري “قرارًا”

لو سألت مديرًا تنفيذيًا: لماذا نحتاج ERP؟ سيجيبك بطرق مختلفة، لكن جوهرها واحد: “أريد أن أرى الصورة بسرعة وأتحكم بالتكلفة والمخاطر.”
النتيجة التي يبحث عنها ليست “إدخال بيانات” بل قرار. لذلك، التقني المؤثر لا يبدأ بـ كيف نبني؟ بل يبدأ بـ:

• ما القرار الذي نريد تحسينه؟

• من صاحب القرار؟

• ما تكلفة التأخير أو الخطأ في القرار؟

عندما تفهم ذلك، ستكتشف أن بعض “الميزات” ليست أولوية، وأن بعض “التفاصيل الصغيرة” هي التي تصنع الأثر.

2) الدرس الثاني: افهم العملية قبل الشاشات

الشاشات قد تُجمّل الفوضى. لكن العملية هي التي تصنع الانضباط.
قبل تصميم أي شاشة، اسأل: ما مسار العمل الحقيقي؟ أين تتوقف المعاملة؟ من يراجع؟ متى تتعطل؟ لماذا تتعطل؟

فهم Business للتقنيين يعني أن تمتلك القدرة على قراءة التشغيل مثلما تقرأ الكود:

• أين يحدث التكرار؟

• أين يحدث الهدر؟

• أين يحدث “تسريب” المسؤولية؟

• ما الخطوة التي يكرهها الموظف لأنها بلا قيمة؟

إن لم تُشخّص ذلك، ستبني نظامًا سريعًا… يُسرّع الأخطاء نفسها.

3) الدرس الثالث: “الألم التشغيلي” أهم من “الطلب الوظيفي”

كثير من المتطلبات تأتي بصيغة: “نحتاج زر… نحتاج تقرير… نحتاج صلاحية…”
لكن السؤال الذي يغيّر جودة الحل هو: لماذا؟

اطلب من صاحب الطلب أن يصف الألم بجملة واضحة:

• “يتأخر إغلاق الشهر لأن الفواتير تصل متأخرة وبلا توحيد.”

• “نخسر فرص مبيعات لأن المتابعة غير منضبطة.”

• “ترتفع تكلفة التشغيل لأن الصرف من المخزون دون ضوابط.”

هنا ينتقل النقاش من “ماذا نبني؟” إلى “ما الذي نصلحه؟” وهذا هو جوهر التحول.

4) الدرس الرابع: المتطلبات بلا قياس = مشروع بلا دليل نجاح

لنقلها بوضوح: أي متطلب لا يمكن قياس أثره غالبًا سيصبح “زحمة” داخل النظام.
ضع قياسًا قبل أن تضع مواصفة.

أمثلة لمؤشرات عملية (KPIs) تربط النظام بالنتيجة:

• زمن دورة الموافقة (Approval Cycle Time)

• نسبة الالتزام بالإجراءات (Process Compliance Rate)

• زمن إغلاق الفترة المالية (Month-End Close Time)

• نسبة الأخطاء في البيانات (Data Error Rate)

• تكلفة المعاملة الواحدة (Cost per Transaction)

• دقة المخزون (Inventory Accuracy)

هنا يصبح الـ ERP ليس قاعدة بيانات فقط، بل “آلة قياس” تربط التشغيل بالحوكمة.

5) الدرس الخامس: لا تبنِ “حلًا عامًا”… صمّم “قرارًا محددًا”

الأنظمة القوية تُغريك بالتوسع: كل شيء ممكن، وكل شيء متاح. لكن Business لا يحتاج كل شيء دفعة واحدة.
ابدأ بـ قرار واحد حساس واجعله أفضل بشكل واضح.

مثال في المشتريات:
بدل أن تقول “نطبق دورة مشتريات كاملة”، ابدأ بقرار:
“متى نعيد الطلب؟ وبأي كمية؟ ومن أي مورد؟”
ثم اربط ذلك ببيانات الأصناف، وحدود إعادة الطلب، وأداء الموردين، واعتمادات الصرف.

بهذه الطريقة، تتحول المنظومة من إجراءات إلى قرار تجاري يقلل التكلفة ويرفع التوافر.

6) الدرس السادس: الحوكمة ليست “تعقيد”… الحوكمة هي منع التكرار وإغلاق الثغرات

حين يتضايق الفريق من الحوكمة، فغالبًا لأن الحوكمة قُدمت كقيود، لا كقيمة.
الحوكمة الصحيحة تُعرَّف ببساطة: من يملك القرار؟ وعلى أي أساس؟ وبأي سجل تدقيق؟

في بيئات التحول الرقمي، الحوكمة تحمي المشروع من:

• تضارب الصلاحيات

• ازدواجية الإجراءات

• التقارير المتناقضة

• الاعتماد على “اجتهاد الأشخاص” بدل النظام

وهنا يظهر دور التقني الشريك: يترجم الحوكمة إلى قواعد واضحة داخل النظام، لا إلى مستندات منسية.

7) الدرس السابع: إدارة التغيير ليست دورة تدريب… بل إعادة تشكيل سلوك

تدريب المستخدمين ضروري، لكنه ليس كافيًا.
إدارة التغيير تعني: هل سيتصرف الناس غدًا بشكل مختلف لأن النظام موجود؟

اسأل هذه الأسئلة:

• ما السلوك الذي نريد تثبيته؟

• ما السلوك الذي نريد إيقافه؟

• ما الذي سيجعل الموظف “يعود للطريقة القديمة”؟

• ما الحافز؟ وما الضبط؟ وما الرقابة؟

إذا لم تُصمم النظام ليقود السلوك (تنبيهات، صلاحيات، مسارات موافقة، إلزام حقول، تقارير متابعة)، ستنتصر العادة القديمة… وسيُتهم النظام بالفشل.

جدول يربط “سؤال Business” بـ “مخرج تقني” قابل للقياس

أسئلة شائعة تساعد فريق التقنية

هل لازم التقني يصير “إداري”؟
لا. لكنه لازم يفهم هدف التشغيل ومؤشرات النجاح حتى يبني الحل الصحيح.

كيف أعرف أني فهمت البيزنس؟
إذا قدرت تلخص الهدف في “KPI واحد” وتشرح كيف النظام سيحسنه، فأنت على الطريق الصحيح.

وش أكبر خطأ؟
تنفيذ نظام فوق واقع غير منضبط… فتُرقمن الفوضى بدل أن تُصلحها.

الخلاصة

إذا كنت تقني وتبي تكون شريك قرار… لا توقف عند الكود.
افهم Business: الهدف، الألم، والقياس.

• الموقع الرسمي للبودكاست:

  https://btechpodcast.com/

  👉 منصة Key Smart Applications

  www.ksasupport.com