معظم المنشآت التي تشتري نظام إدارة تشتريه من عرض تجريبي، والعرض التجريبي مصمم ليبدو جميلاً لا ليشبه عملك. فتنتهي بنظام فيه كل شيء إلا الشيء الواحد الذي يستهلك نصف وقت فريقك. هذا المقال مكتوب من الجهة المعاكسة: ما يحتاجه كل قطاع فعلاً، وأي الشاشات تهم، وأين يُخفي نموذج البيانات فخاً يظهر بعد سنة، وبماذا تبدأ.
ما سأكتبه هنا من أنظمة بنيتها وسلّمتها، ومن أنظمة أُعطيت لي لإنقاذها بعد أن بناها غيري. والنوع الثاني أعلّم أكثر، لأن النظام الفاشل يخبرك بدقة بالسؤال الذي لم يُسأل في البداية.
لماذا تضلّلك العروض التجريبية
العرض التجريبي يُبنى على بيانات نظيفة ومسار واحد مثالي. تضغط ثلاث مرات فتظهر فاتورة، وتضغط مرتين فيظهر تقرير ملوّن. ولا شيء من ذلك كذب، لكنه يحذف كل ما يجعل الأنظمة صعبة.
عملك الحقيقي فيه الاستثناء. العميل الذي يدفع نصف المبلغ نقداً والنصف بعد شهر. الطلب الذي يُعدّل بعد تأكيده. الموظف الذي يحتاج رؤية الأسعار دون القدرة على تغييرها. الفرع الذي يعمل بساعات مختلفة في رمضان. المورّد الذي يرسل كشفاً شهرياً في ملف إكسل بتنسيق خاص به. هذه ليست حالات طرفية، بل هي عملك، وهي التي تحدد هل النظام سيُستخدم أم سيُترك.
السؤال الذي أطرحه على كل عميل بعد مشاهدة عرض تجريبي أعجبه: اطلب منهم إدخال أصعب حالة عندك، لا أسهلها. أصعب حالة واحدة تكشف عن النظام أكثر من ساعة عرض.
الأسئلة الأربعة التي تحدد أي نظام إدارة
قبل الحديث عن قطاعك، هذه الأربعة تحدد شكل أي نظام أعمال، وجوابها عندك لا عند المطور.
ما الشيء الذي تتبعه؟
كل نظام أعمال يتبع شيئاً واحداً أساسياً وكل ما حوله مشتق منه. في العقار هو الوحدة. وفي العيادة هو الموعد. وفي المكتب القانوني هو القضية. وفي التوصيل هو الطلب. وفي المقاولات هو البند في العقد. وفي التدريب هو التسجيل.
تحديد هذا الشيء بدقة هو أهم قرار في المشروع، لأن كل شيء آخر يُعلّق عليه. والأنظمة التي تفشل عادة لم تحدده، أو حددت شيئاً خاطئاً، فصارت كل تقاريرها تحتاج حسابات يدوية.
ما حالاته وكيف ينتقل بينها؟
الشيء الذي تتبعه يمر بحالات. الوحدة متاحة ثم محجوزة ثم مبيعة ثم مسلّمة. والطلب جديد ثم مقبول ثم قيد التحضير ثم في الطريق ثم مسلّم أو مرتجع. اكتب هذه الحالات على ورقة، واكتب من يملك تغيير كل انتقال، واكتب ما يحدث عند الرجوع للخلف.
الرجوع للخلف هو الجزء الذي ينسى الجميع تحديده، وهو أكثر ما يسبب مشاكل حقيقية. طلب مسلّم رجع. حجز مؤكد أُلغي بعد الدفع. قضية مغلقة أُعيد فتحها. إن لم يُصمم الرجوع، فسيُنفّذ يدوياً في قاعدة البيانات، وهذا أسوأ ما يمكن أن يحدث لنظام.
من يستخدمه وما يستطيع كل منهم؟
اكتب قائمة الأدوار، وتحت كل دور من ثلاثة إلى خمسة أشياء يفعلها، وشيئاً واحداً على الأقل لا يجوز أن يفعله. هذا الأخير هو الذي يُنسى، وهو تعريف الصلاحيات.
وتجنّب خطأ شائعاً: الأدوار ليست المسميات الوظيفية. مدير الفرع ومدير المبيعات قد يكونان نفس الدور في النظام، وموظف واحد قد يحمل دورين. صمّم الأدوار على ما يُفعَل لا على من يفعله.
أي أرقام تريد رؤيتها آخر الشهر؟
ابدأ من التقرير النهائي وارجع للخلف. إن أردت معرفة هامش الربح لكل فرع، فالنظام يجب أن يسجّل التكلفة مع كل عملية لا السعر فقط. وإن أردت معرفة سبب فقدان العملاء، فيجب أن يكون هناك حقل لسبب الخسارة يُجبر المستخدم على اختياره.
هذه الطريقة في التفكير توفّر أكثر من أي شيء آخر، لأن إضافة حقل في البداية مجانية وإضافته بعد سنة تعني أنك تملك بيانات ناقصة لسنة كاملة لا يمكن استرجاعها.
كيف تعرف أنك تحتاج نظاماً فعلاً
ليس كل منشأة تحتاج نظام إدارة، وبعض من يشتريه كان يحتاج تنظيم عمليته أولاً. هذه الإشارات التي أعتبرها كافية.
- نفس المعلومة تُكتب في مكانين أو أكثر، وأحدهما دائماً قديم
- شخص واحد يعرف شيئاً جوهرياً ولا يوجد مكان مكتوب فيه
- الرد على سؤال إداري بسيط يحتاج أكثر من ساعة جمع بيانات
- الأخطاء التي تكلفك مالاً تتكرر بنفس السبب
- لا تعرف أرقامك إلا بعد نهاية الشهر بأسبوعين
- النمو يحتاج تعيين شخص إضافي لعمل إداري لا لعمل منتج
- فقدت عميلاً أو طلباً لأنه لم يتابعه أحد
الإشارة الأولى والأخيرة هما الأقوى. إعادة كتابة البيانات مؤشر مباشر على ساعات تُهدر أسبوعياً ويمكن حسابها. وفقدان طلب لأن لا أحد تابعه مؤشر على إيراد يتسرب وهو عادة أكبر من تكلفة النظام.
وإشارة معاكسة تقول لا تبنِ بعد: إن كانت عمليتك نفسها غير محددة وتتغير كل شهر، فبرمجتها الآن تثبّت ارتباكاً. نظّمها على ورق أو في جدول إكسل أولاً حتى تستقر، ثم ابنِها. النظام يسرّع عملية موجودة ولا يصنع واحدة.
الأساس المشترك في كل نظام أعمال
قبل أي خصوصية قطاعية، هذه البنية موجودة في كل نظام بنيته، وهي تقريباً نصف العمل. إن قدّم لك أحد عرضاً لا يذكر شيئاً منها فهو لم يقدّر نظاماً.
الهوية والصلاحيات
دخول آمن، وأدوار، وصلاحيات مفروضة على الخادم لا مخفية في الواجهة. وتحقق بخطوتين للحسابات الإدارية على الأقل. وقدرة على تعطيل حساب فوراً عندما يترك موظف العمل، وهذا بند يُنسى دائماً ويكون مهماً في أسوأ وقت.
سجل من فعل ماذا
كل تغيير مهم يُسجّل بمن ومتى وما كانت القيمة قبله. يبدو بنداً إضافياً حتى أول مرة تحتاج معرفة من غيّر سعراً أو حذف سجلاً، وعندها يصبح أهم ميزة في النظام. وفي الأنظمة التي تحمل مالاً أو بيانات شخصية هو ضرورة لا رفاهية.
نموذج بيانات يعبّر عن عملك لا عن لحظتك
الاختبار بسيط: هل تستطيع فتح فرع جديد، أو إضافة نوع خدمة، أو عملة، أو خطة سعر، من لوحة الإدارة بدون مطور؟ إن كان الجواب لا فنموذجك يصف وضعك الحالي فقط، وكل نمو سيكون مشروعاً.
الإشعارات والتنبيهات
النظام الذي ينتظر منك فتحه لترى ما حدث نظام ستنساه. والمفيد منها قليل ومحدد: تنبيه عند وصول طلب جديد، وتذكير قبل موعد، وتحذير عند تجاوز حد، وتقرير يومي أو أسبوعي يصل بالبريد أو واتساب بدون أن يطلبه أحد.
وقاعدة أتبعها: كل إشعار يجب أن يكون قابلاً للتصرف. إشعار لا يستطيع مستلمه فعل شيء بناء عليه سيُتجاهل، وبعد عشرة منها ستُتجاهل الإشعارات المهمة معه.
التقارير التي تُقرأ
عدد قليل من التقارير التي يفتحها الناس فعلاً أفضل من عشرين لا يفتحها أحد. واجعلها قابلة للتصدير، لأن المحاسب أو المستثمر سيطلب ملفاً مهما كان التقرير جميلاً على الشاشة.
النسخ الاحتياطي والاستعادة
نسخ آلية يومية، ومحتفظ بها في مكان آخر غير الخادم نفسه، وجرّب أحدهم استعادة واحدة فعلاً. النسخة الاحتياطية التي لم تُجرّب استعادتها ليست نسخة احتياطية بل أمنية.
العقار والتطوير العقاري
الشيء الذي تتبعه هو الوحدة، وكل ما عداه معلّق عليها. وأكبر خطأ في هذا القطاع أن يُبنى النظام حول العميل أو حول المبيعات، فتصبح حالة الوحدة مشتقة من آخر عملية بيع بدل أن تكون هي الحقيقة.
المسار الحقيقي
الوحدة متاحة، ثم يحجزها مشترٍ بمبلغ تحجيز لمدة محددة، ثم إما يكمل أو ينتهي الحجز وتعود متاحة آلياً. ثم عقد، ثم دفعات بجدول، ثم تسليم بمحضر وملاحظات، ثم ضمان لمدة. وفي كل نقطة قد يتغير شيء: مشترٍ ينقل عقده، أو يُلغى عقد، أو تُدمج وحدتان.
الشاشات التي تهم
شاشة مخزون الوحدات بحالة ملوّنة واضحة هي الشاشة التي سيفتحها فريق المبيعات عشرين مرة يومياً، فاستثمر فيها. وشاشة جدول الدفعات للمشتري الواحد، بما تم وما تأخر. وشاشة العمولات لأنها سبب نصف الخلافات الداخلية في شركات العقار. وشاشة تسليم فيها قائمة فحص وصور.
فخ نموذج البيانات
الحجز يجب أن يكون كياناً له مدة وتنتهي آلياً، لا حالة على الوحدة يغيّرها شخص يدوياً. رأيت أكثر من نظام عقاري تُحجز فيه الوحدات ولا يحرّرها أحد، فيتجمد نصف المخزون على ورق وهو متاح فعلاً. والقاعدة: كل شيء له مدة يجب أن يكون له تاريخ انتهاء ومهمة مجدولة تتعامل معه.
بماذا تبدأ
بمخزون الوحدات والحجز وجدول الدفعات. العمولات والتسليم والضمان مرحلة ثانية. وموقع العرض العام للمشاريع مشروع منفصل ويمكن أن يسبق أو يتبع، لكنه يجب أن يقرأ حالة الوحدات من النظام نفسه لا من ملف يُحدّث يدوياً.
إدارة الأملاك والإيجارات
قطاع قريب من السابق ومختلف تماماً في النموذج، لأن الشيء المتبوع هنا ليس الوحدة بل العقد. العقد له تاريخ بداية ونهاية وقيمة ودفعات دورية وتجديد، والوحدة مجرد صفة فيه.
المسار الحقيقي
وحدة شاغرة، ثم معاينة، ثم عقد بمدة وشيكات أو دفعات، ثم تحصيل دوري، ثم طلبات صيانة من الساكن، ثم تجديد أو إخلاء مع تسوية التأمين. والجزء الذي يستهلك الوقت في الواقع ليس التعقيد بل التكرار: عشرات العقود لها استحقاقات في نفس الأسبوع.
الشاشات التي تهم
لوحة بالمستحقات هذا الشهر وما تأخر، وهي الشاشة التي تعيد التكلفة وحدها. وشاشة العقود المنتهية خلال ستين يوماً، لأن التجديد المتأخر يعني شهراً فارغاً. وشاشة طلبات الصيانة بحالتها، لأن الساكن الذي يرى طلبه يُتابع يجدّد أكثر.
فخ نموذج البيانات
احفظ الدفعات كجدول استحقاقات منفصل عن العقد لا كحقول في العقد. الزيادة السنوية، والتأجيل، والدفعة الجزئية، والتسوية عند الإخلاء كلها تحتاج سجلاً لكل دفعة. والأنظمة التي تخزّن قيمة سنوية ورقم شيك واحد تنكسر أول مرة يدفع ساكن على أقساط مختلفة.
بماذا تبدأ
بالعقود وجدول التحصيل والتنبيهات. طلبات الصيانة وبوابة الساكن مرحلة ثانية مفيدة لكنها لا تسدد التكلفة بسرعة التحصيل.
المكاتب والشركات القانونية
الشيء المتبوع هو القضية أو التكليف، والسرية ليست ميزة في هذا القطاع بل هي البنية. القرار الأول في المشروع ليس تصميم شاشة بل من يرى ماذا.
المسار الحقيقي
طلب استشارة يصل، ثم فحص مبدئي للتعارض في المصالح وللصلاحية، ثم عرض أتعاب، ثم تكليف موقّع، ثم عمل على القضية بمستندات وجلسات ومواعيد نظامية، ثم فوترة إما بالساعة أو بمرحلة أو بمبلغ ثابت، ثم إغلاق وأرشفة بمدة احتفاظ.
الشاشات التي تهم
شاشة المواعيد النظامية القادمة، لأن فوات موعد في هذا القطاع ليس خطأ إدارياً بل مسؤولية. وشاشة القضية الواحدة بكل مستنداتها وتاريخها في مكان واحد. وشاشة ساعات العمل غير المفوترة، لأنها الإيراد الذي ينسى المكتب تحصيله.
فخ نموذج البيانات
الصلاحيات يجب أن تكون على مستوى القضية لا على مستوى النظام. محامٍ له حق كامل على قضاياه وصفر على قضايا زميله، والشريك يرى الكل، والمتدرب يرى ما أُسند له فقط. وهذا قرار معماري يُتخذ في البداية، وتحويل نظام بصلاحيات عامة إلى صلاحيات على مستوى السجل عمل يقارب إعادة البناء.
وفخ ثانٍ: مسار الاستقبال العام. كل ما يكتبه عميل محتمل في النموذج يصبح في حوزتك من لحظة إرساله، بما يشمل تفاصيل قد لا يريد المكتب حملها قبل وجود تكليف. اجمع ما يكفي للتقييم فقط، ووثّق مدة الاحتفاظ بما لم يتحول إلى تكليف.
بماذا تبدأ
بإدارة القضايا والمستندات والمواعيد النظامية. الفوترة بالساعة مرحلة ثانية إلا إن كان هذا نموذج عملك الأساسي. والمنصة العامة بشجرة الخدمات مشروع مستقل يولّد الطلبات، وهو غالباً الأسبق في العائد.
العيادات والرعاية الصحية
الشيء المتبوع هو الموعد، وبيانات المرضى ترفع سقف الأمان للمشروع كله بلا نقاش.
المسار الحقيقي
مريض يبحث عن وقت، فيجب أن يرى التوفّر الحقيقي لا قائمة أوقات ثابتة. ثم يحجز، ويصل تأكيد، وتذكير قبل الموعد. ثم حضور أو عدم حضور، وعدم الحضور هو أكبر تسريب مالي في العيادات ويمكن تقليصه بالتذكير والعربون. ثم الجلسة، ثم ملف يُحدّث، ثم متابعة أو جلسة تالية.
الشاشات التي تهم
شاشة اليوم لموظف الاستقبال، فيها كل مواعيد اليوم وحالتها وزر واحد لكل إجراء. هذه الشاشة وحدها تحدد هل سيُستخدم النظام. وشاشة التقويم للطبيب. وشاشة ملف المريض بتاريخه.
فخ نموذج البيانات
الغرفة مورد منفصل عن الطبيب. موعد يحتاج طبيباً وغرفة ومدة، والتوفّر هو تقاطع الثلاثة. الأنظمة التي تحجز على الطبيب فقط تنتج حجزين في غرفة واحدة، وهذا يحدث في أول أسبوع تشغيل. وأضف إلى ذلك أن مدة الإجراء تختلف: تنظيف أسنان ثلاثون دقيقة وزراعة ساعتان، فالمدة صفة في نوع الخدمة لا رقم ثابت في النظام.
بماذا تبدأ
بالحجز والتوفّر والتذكيرات، وهذه وحدها تسدد ثمنها من تقليل عدم الحضور. حسابات المرضى والدفع الإلكتروني والتقارير مرحلة ثانية. وأي تكامل مع نظام عيادة قائم يجب أن يُفحص قبل التسعير لا بعده، لأنه عادة أكبر بند منفرد.
التعليم والتدريب
الشيء المتبوع هو التسجيل، والفرق الجوهري في هذا القطاع بين بيع للأفراد وبيع للشركات، وهو يغيّر النظام أكثر من أي ميزة.
المسار الحقيقي للأفراد
متدرب يسجّل في برنامج، فيدفع أو يُقسّط، فيحضر أو يشاهد، فيتقدّم ويُقيَّم، فيحصل على شهادة. ومسار الشركات مختلف: شركة تشتري مقاعد، فتوزّعها على موظفين، فتتابع تقدم فريقها، فتطلب تقريراً لقسم الموارد البشرية، فتُفوتر مرة واحدة لا لكل متدرب.
الشاشات التي تهم
شاشة المدرب يجب أن تكون بسيطة جداً، لأن المدرب الذي يجد النظام مزعجاً سيرجع لجدول إكسل ويضيع تقدم المتدربين. وشاشة تقدم المجموعة للعميل المؤسسي، وهي سبب تجديد العقود. وشاشة الشهادات بتحقق يمكن لصاحب عمل أن يستخدمه.
فخ نموذج البيانات
افصل البرنامج عن النسخة المطروحة منه. البرنامج محتوى ووصف، والنسخة لها تاريخ ومدرب ومقاعد وسعر. الأنظمة التي تخلط الاثنين لا تستطيع طرح نفس البرنامج مرتين بسعرين أو بمدرّبين مختلفين دون تكرار المحتوى كله، وبعد سنة يصبح لديك أربعون نسخة من نفس الوصف وتحديث واحد يحتاج أربعين تعديلاً.
وافصل المتدرب عن المشتري. من يدفع ليس دائماً من يحضر، وهذا هو جوهر البيع المؤسسي. جرّبت أكاديمية OGS هذا بوضوح: عملاؤها شركات نفط وغاز وصناعات ثقيلة تشتري تدريباً معتمداً لفرقها، فالنظام يُبنى حول الشركة والمجموعة لا حول الفرد.
بماذا تبدأ
بالبرامج والتسجيل والدفع. التقييم والشهادات الآلية والطبقة المؤسسية بعدها، إلا إن كان البيع المؤسسي هو نموذجك الأساسي فتبدأ به.
المطاعم وخدمات الأغذية
الشيء المتبوع هو الطلب، والدافع الاقتصادي في هذا القطاع واضح وقابل للحساب: العمولة التي تأخذها منصات التوصيل من كل طلب.
المسار الحقيقي
عميل يفتح القائمة، فيختار ويعدّل، فيحدد توصيلاً أو استلاماً، فيدفع أو يختار الدفع عند الاستلام، فيصل الطلب للمطبخ، فيُحضَّر، فيخرج، فيُسلَّم. والجزء الذي يُستهان به هو ما بين وصول الطلب ووصوله للمطبخ: إن اعتمد على شخص يراقب شاشة فستفقد طلبات في وقت الضغط.
الشاشات التي تهم
شاشة المطبخ، بخط كبير وتنبيه صوتي وزر واحد لكل حالة. وهي الشاشة الأقل جمالاً والأكثر أهمية. وشاشة القائمة في الإدارة، بحيث يستطيع المدير إيقاف طبق نفد في ثانيتين من جواله.
فخ نموذج البيانات
الخيارات والإضافات يجب أن تُنمذج كما يعمل المطبخ لا كما تبدو في القائمة. حجم، ومستوى حرارة، وإضافات بسعر، وبدائل بلا سعر، وبعضها إجباري وبعضها متعدد الاختيار. ومجموعة الخيارات يجب أن تكون قابلة لإعادة الاستخدام على عدة أطباق، وإلا سيكون تحديث سعر إضافة واحدة تعديلاً على ثلاثين طبقاً.
وفخ ثانٍ: ساعات العمل والاستثناءات. المطعم يغلق في وقت، ويفتح بساعات مختلفة في رمضان، ويقفل يوماً لصيانة. اجعل الاستثناء كياناً يضيفه المدير، لا تعديلاً في الكود.
بماذا تبدأ
بالقائمة والطلب وشاشة المطبخ ونطاقات التوصيل. برامج الولاء والتطبيق وحسابات العملاء مرحلة ثانية تُموّل من العمولة الموفّرة. بنيت هذا الترتيب بالضبط لمطعم، وكان قرار تأجيل الثلاثة هو سبب نجاح المشروع لا نقصاً فيه.
التجزئة والتوزيع
الشيء المتبوع هو حركة المخزون، لا المنتج. المنتج تعريف ثابت، والحقيقة التي يحتاجها عملك هي كم منه وأين ولماذا تغيّر.
المسار الحقيقي
شراء من مورّد، فاستلام في مستودع بكمية قد تختلف عن أمر الشراء، فتوزيع على فروع، فبيع أو إرجاع أو تلف أو جرد يكشف فرقاً. وكل واحدة من هذه حركة يجب أن تُسجّل بسببها، وجمعها يعطي الرصيد.
الشاشات التي تهم
شاشة أرصدة متعددة الفروع. وشاشة المنتجات التي ستنفد قريباً مبنية على معدل البيع لا على حد ثابت. وشاشة فروق الجرد، لأنها المكان الذي تظهر فيه مشاكل حقيقية في التشغيل.
فخ نموذج البيانات
لا تخزّن الرصيد كرقم تعدّله. خزّن الحركات واحسب الرصيد منها. الرقم المعدّل مباشرة يفقد المطابقة أول مرة يحدث خطأ، ولا توجد طريقة لمعرفة أين اختلف. أما الحركات فتسمح لك بسؤال النظام لماذا الرصيد عشرة، فيجيب بقائمة.
وافصل المنتج عن المتغير. قميص أزرق مقاس كبير ليس منتجاً مستقلاً بل متغيراً، وخلط الاثنين يجعل كل تقرير مبيعات بلا معنى.
بماذا تبدأ
بالمنتجات والحركات والأرصدة والجرد. المشتريات وأوامر الشراء بعدها، والتكامل مع نقاط البيع أو المتجر الإلكتروني ثالثاً، بشرط أن يكون المخزون مصدر الحقيقة الوحيد لكل القنوات.
اللوجستيات والتوصيل
الشيء المتبوع هو الشحنة، والبند الذي يفاجئ الجميع هو الدفع عند الاستلام، لأنه يحوّل النظام من تتبع إلى نظام مالي.
المسار الحقيقي
شحنة تُسجَّل، فتُسنَد لمندوب، فيستلمها، فيحاول التسليم، فينجح أو يفشل لسبب، فإن فشل تُعاد المحاولة أو تُرجَع. وإن كان الدفع عند الاستلام فالمندوب يحمل نقداً يجب تسويته في نهاية اليوم. وإعادة المحاولة هي الحالة التي تُنسى في التصميم وهي شائعة جداً في الواقع.
الشاشات التي تهم
تطبيق المندوب، ويجب أن يعمل على شبكة سيئة وأن يحفظ الإجراء محلياً ويرسله عند توفر الاتصال. هذا ليس تحسيناً بل متطلب أساسي، فالمندوب يسلّم في مواقف أقبية ومناطق تغطيتها ضعيفة. وشاشة التوزيع للمشرف. وشاشة تسوية المندوبين النقدية.
فخ نموذج البيانات
محاولة التسليم كيان مستقل عن الشحنة. شحنة واحدة قد يكون لها ثلاث محاولات لكل منها وقت ومندوب وسبب فشل وموقع. الأنظمة التي تضع حالة واحدة على الشحنة تفقد تاريخ المحاولات، وهو بالتحديد ما تحتاجه عند خلاف مع عميل أو عند قياس أداء مندوب.
والنقد يحتاج نموذجاً ماليا صريحاً: عهدة المندوب، والتحصيل، والتوريد، والفرق. منصة تمّم في صعيد مصر كانت تحمل هذا كله مع تطبيق أندرويد، والدرس منها أن الجزء المالي أكبر من جزء التتبع وإن كان أقل بروزاً في العرض التجريبي.
بماذا تبدأ
بالشحنات والتوزيع وتطبيق المندوب وإثبات التسليم. التتبع المباشر للعميل والتسعير بالنطاقات والتكامل مع المتاجر بعدها.
المقاولات والمشاريع الهندسية
الشيء المتبوع هو البند في جدول الكميات، لا المشروع. والسبب أن كل شيء مالي وزمني في هذا القطاع يُقاس على مستوى البند: التنفيذ، والمستخلص، والتكلفة الفعلية، والتعديل.
المسار الحقيقي
عقد بجدول كميات، فتنفيذ تدريجي بنسب، فمستخلص دوري يُقدَّم ويُعتمد أو يُخفَّض، فدفعة بعد خصم الضمان والمقدم. وبالتوازي أوامر تغيير تضيف أو تحذف بنوداً، ومشتريات ومقاولون من الباطن وتكاليف يومية.
الشاشات التي تهم
شاشة نسب التنفيذ مقابل المخطط، لأن الفرق بينهما هو التأخير قبل أن يصبح مشكلة. وشاشة المستخلص الواحد بما قُدّم وما اعتُمد. وشاشة التكلفة الفعلية مقابل المقدّرة لكل بند، وهي التي تخبر المالك هل المشروع رابح قبل نهايته لا بعدها.
فخ نموذج البيانات
أمر التغيير يجب أن يكون نسخة جديدة من جدول الكميات لا تعديلاً عليه. الحفاظ على الأصل ضروري لأن كل مطالبة أو خلاف يرجع إلى ما كان متفقاً عليه في البداية. والأنظمة التي تعدّل الجدول في مكانه تفقد القدرة على إثبات أي شيء.
بماذا تبدأ
بجدول الكميات ونسب التنفيذ والمستخلصات. التكلفة الفعلية والمشتريات والمقاولون من الباطن مرحلة ثانية، وهي التي تحوّل النظام من متابعة إلى إدارة ربحية.
الحج والعمرة والسياحة
الشيء المتبوع هو الحجز، والخصوصية الهندسية في هذا القطاع أن الطلب مرتبط بالتقويم ومتركز في نوافذ قصيرة جداً.
المسار الحقيقي
باقة تُعرض بمكوناتها، فيحجز عميل لعدد أفراد، فيدفع كلياً أو جزئياً، فتُؤكّد المكونات مع المورّدين، فقد يتغير مكوّن بعد التأكيد، فتُصدر وثائق، فتُنفّذ الرحلة بمراحل.
الشاشات التي تهم
شاشة الحجز بأفرادها ووثائقهم، لأن النقص في وثيقة فرد واحد يعطّل المجموعة. وشاشة المكونات وحالة تأكيدها مع كل مورّد. وشاشة الدفعات، لأن الدفع الجزئي هو القاعدة في هذا القطاع لا الاستثناء.
فخ نموذج البيانات
احفظ مكونات الباقة على الحجز نفسه لا كمرجع للباقة. إن تغيّر فندق في الباقة العام القادم فلا يجوز أن يتغير أثراً رجعياً في حجوزات العام الماضي. وهذا من أكثر الأخطاء التي رأيتها في أنظمة هذا القطاع، ونتيجته أن سجلاتك التاريخية تصبح خاطئة بهدوء.
وفخ ثانٍ تقني: حالة الطلب يجب أن تُصمم لشبكة غير موثوقة. المستخدم في الحرم على شبكة مزدحمة قد يرسل الطلب مرتين أو ينقطع قبل أن يرى النتيجة. فأي عملية مالية تحتاج مفتاحاً يمنع التكرار، وأي شاشة تحتاج أن تخبر المستخدم بحالته الحقيقية عند العودة. بنيت في هذا القطاع لهدية وتفويض ومعين ووسيلة، والدرس يتكرر في كل واحدة.
بماذا تبدأ
بالباقات والحجز والدفعات والوثائق. إدارة المورّدين وخط سير الرحلة والواجهة البرمجية للشركاء بعدها.
الاستشارات والخدمات المهنية
الشيء المتبوع هو الفرصة، والقيمة في هذا القطاع ليست في إدارة العمل بل في ما يحدث للطلب الوارد في أول ساعة.
المسار الحقيقي
طلب يصل، فيُصنّف ويُسنَد، فيُتصل به، فيُقيَّم هل يستحق عرضاً، فعرض، فقبول أو رفض بسبب مسجّل، فتنفيذ بمخرجات ومراحل، ففوترة.
الشاشات التي تهم
شاشة الطلبات الجديدة التي لم يتابعها أحد، وهي الشاشة التي تجد فيها إيراداً مفقوداً من اليوم الأول. وشاشة الفرص بمرحلتها وقيمتها. وشاشة أسباب الخسارة، وهي أرخص أداة تحسين عندك إن استخدمتها.
فخ نموذج البيانات
أجبر على تسجيل سبب الخسارة من قائمة محددة لا في حقل نصي حر. الحقل الحر يُترك فارغاً أو يُكتب فيه "غير مهتم" فلا يعني شيئاً. والقائمة المحددة تعطيك بعد ثلاثة أشهر معلومة قابلة للتصرف: أنك تخسر على السعر، أو على التوقيت، أو على نطاق لا تقدّمه.
بماذا تبدأ
باستقبال الطلبات وتوجيهها ومتابعتها. وأضيف ملاحظة من مشروع سيجما بي إم أو: عندما يكون المُخرج نفسه هو المنتج، كما في الحوكمة والدراسات، فالنظام يحتاج طبقة موافقة صريحة بحيث لا يصل شيء إلى بنك أو مستثمر قبل أن يعتمده شخص بالاسم. التحليل آلي والموافقة بشرية، وهذا الترتيب لا يُقلب.
الخدمات الميدانية والصيانة
الشيء المتبوع هو أمر العمل، والفرق بين هذا القطاع والتوصيل أن الفني يبقى في الموقع وقتاً ويستهلك قطعاً.
المسار الحقيقي
عميل يبلّغ عن مشكلة، فيُفتح أمر عمل بأولوية، فيُجدول لفني بمهارة مناسبة ووقت متاح، فيذهب، فيشخّص، فيحتاج قطعاً قد لا تكون معه، فيُنجز أو يُجدول زيارة ثانية، فتُسجّل قطع وساعات، فتُفوتر أو تُخصم من عقد صيانة.
الشاشات التي تهم
شاشة الجدولة بالمهارات والمناطق، لأن إرسال فني بلا المهارة الصحيحة يكلف زيارة كاملة. وتطبيق الفني بقائمة فحص وصور وتوقيع العميل. وشاشة عقود الصيانة بما استُهلك منها.
فخ نموذج البيانات
الزيارة كيان منفصل عن أمر العمل. أمر عمل واحد قد يحتاج ثلاث زيارات، وكل زيارة لها فني وقطع وساعات ونتيجة. ومن يجعل أمر العمل والزيارة شيئاً واحداً لا يستطيع قياس كم مرة لم تُحل المشكلة في الزيارة الأولى، وهذا أهم مؤشر أداء في هذا القطاع.
بماذا تبدأ
بأوامر العمل والجدولة وتطبيق الفني. المخزون وعقود الصيانة والفوترة بعدها.
الأندية الرياضية والصالات
الشيء المتبوع هو العضوية، وهي عقد متجدد لا عملية بيع، وهذا الفرق يحدد النظام كله.
المسار الحقيقي
زائر يأخذ جلسة تجريبية، فيشترك بخطة لها مدة، فيدخل بتحقق، فقد يجمّد العضوية أو يحوّلها، فيحضر حصصاً لها طاقة محدودة، فيجدّد أو ينقطع. والانقطاع هنا هو العدو، لأن كلفة جلب عضو جديد أضعاف كلفة إبقاء عضو.
الشاشات التي تهم
شاشة الأعضاء الذين لم يحضروا منذ أسبوعين، لأن التدخل في ذلك الوقت يمنع عدم التجديد. وشاشة التجديدات القادمة. وشاشة حجز الحصص بطاقتها.
فخ نموذج البيانات
التجميد يجب أن يكون كياناً له فترة تمدّ العضوية آلياً، لا تعديلاً يدوياً على تاريخ الانتهاء. التعديل اليدوي يعني أن أحداً سينسى، وأن الخلاف مع العضو سيكون بلا سجل.
بماذا تبدأ
بالعضويات والتجديد ودخول الأعضاء. حجز الحصص والمدربين الشخصيين والتطبيق بعدها.
الجمعيات والمنظمات غير الربحية
الشيء المتبوع هو الحالة أو المستفيد، والاختلاف الجوهري عن القطاع الربحي أن الشفافية مُخرَج مطلوب لا أثر جانبي.
المسار الحقيقي
مستفيد يتقدّم، فيُفحص استحقاقه بمعايير وبمستندات، فيُعتمد بمبلغ أو خدمة، فيُصرف، فيُوثّق الأثر. وبالتوازي تبرعات تأتي، بعضها مخصص لبرنامج محدد ولا يجوز صرفه في غيره.
الشاشات التي تهم
شاشة الطلبات بمرحلتها، لأن الشفافية تجاه المتقدم تقلل الاتصالات. وشاشة التبرعات المخصصة مقابل المصروف منها، وهي التي تجيب على سؤال المتبرع. وتقرير أثر يمكن نشره.
فخ نموذج البيانات
التبرع المخصص قيد مالي لا وسم. يجب أن يكون للنظام القدرة على منع صرف من رصيد برنامج على برنامج آخر، وأن يعرض الرصيد المتبقي لكل تخصيص. والأنظمة التي تتعامل مع التخصيص كملاحظة نصية لا تستطيع إنتاج التقرير الذي يطلبه المتبرع، وهو التقرير الوحيد المهم.
بماذا تبدأ
بالطلبات والفحص والاعتماد والصرف. إدارة التبرعات وتقارير الأثر مرحلة ثانية مرتبطة بها مباشرة.
المدارس والحضانات
الشيء المتبوع هو الطالب في عام دراسي، والفرق الجوهري عن التدريب أن ولي الأمر طرف ثالث يحتاج شاشته الخاصة ويتواصل كثيراً.
المسار الحقيقي
تقديم، ثم مقابلة أو اختبار، ثم قبول وتسجيل في صف، ثم رسوم مقسّطة، ثم حضور ودرجات وسلوك، ثم تقارير دورية لولي الأمر، ثم ترقية للصف التالي أو تحويل.
الشاشات التي تهم
شاشة ولي الأمر هي أهم شاشة في النظام، وهي التي تقلل المكالمات على الإدارة بشكل محسوس: رسوم الابن، وحضوره، ودرجاته، والإشعارات. وشاشة التحصيل للإدارة. وشاشة المعلم لإدخال الدرجات والحضور بأقل عدد ضغطات ممكن.
فخ نموذج البيانات
اجعل العام الدراسي كياناً أساسياً في النموذج. الطالب ليس في صف، بل الطالب مسجّل في صف في عام محدد. والأنظمة التي تضع الصف كحقل على الطالب لا تستطيع الاحتفاظ بتاريخه ولا إنتاج سجل أكاديمي، وتنكسر أول عملية ترقية في نهاية العام.
وافصل الرسوم عن التسجيل أيضاً: الخصومات للأشقاء، والمنح، والإضافات كالنقل والزي، كلها بنود على حساب الطالب لا حقول في الاستمارة.
بماذا تبدأ
بالتسجيل والرسوم وبوابة ولي الأمر. الدرجات والسلوك والتقارير الأكاديمية مرحلة ثانية، إلا إن كانت مطلوبة نظامياً من اليوم الأول.
العيادات التجميلية والحلاقة والسبا
قريب من العيادات الطبية ومختلف في اثنين: الخدمة مرتبطة بشخص محدد يطلبه العميل بالاسم، والعرض والتسويق جزء من النظام لا خارجه.
المسار الحقيقي
عميل يحجز خدمة مع موظف محدد، فيأتي، فتُنفّذ الخدمة وقد تُضاف خدمات في الموقع، فيدفع، فيُسجّل في برنامج ولاء أو باقة مدفوعة مسبقاً، فيُذكَّر بموعد المتابعة.
الشاشات التي تهم
شاشة اليوم لكل موظف بعمولته المحسوبة، لأن العمولة هي ما يجعل الموظف يدخل البيانات بدقة. وشاشة الباقات المدفوعة مسبقاً وما استُهلك منها. وشاشة العملاء الذين لم يعودوا منذ ستين يوماً.
فخ نموذج البيانات
الباقة المدفوعة مسبقاً التزام مالي لا رصيد نقاط. عشر جلسات مدفوعة مقدماً تعني إيراداً مؤجلاً يُعترف به مع كل جلسة، وأي نظام يعدّ الجلسات فقط دون جانب مالي يُنتج أرقاماً خاطئة في الحسابات. وأضف تاريخ انتهاء للباقة وقاعدة واضحة لما يحدث بعده.
بماذا تبدأ
بالحجز والموظفين والعمولات والباقات. التذكيرات وبرامج الولاء والمتجر بعدها.
المعارض والورش وقطاع السيارات
قطاع له شيئان متبوعان لا واحد: المركبة في المعرض، وأمر الصيانة في الورشة. ومن يحاول توحيدهما في نظام واحد مبكراً يحصل على نظام رديء في الاثنين.
المعرض
المركبة كيان له رقم هيكل ومواصفات وتكلفة شراء وتاريخ دخول، وهو ما يجعل حساب هامش الربح لكل مركبة ممكناً. والمسار: دخول للمخزون، فعرض، فاستفسارات، فتجربة قيادة، فتفاوض، فبيع أو مقايضة، فنقل ملكية وتمويل.
وفخ النموذج هنا: المقايضة عمليتان لا واحدة. بيع مركبة وشراء مركبة بسعر تقديري، وكل واحدة تحتاج سجلها، وإلا استحال معرفة ربح أي منهما.
الورشة
قريبة من الخدمات الميدانية مع فرق أن المركبة تدخل وتبقى. والمسار: استلام بفحص مبدئي وصور، فتشخيص وعرض سعر، فموافقة العميل، فعمل بقطع وساعات، فاختبار، فتسليم.
وشاشة موافقة العميل على عرض السعر هي التي تمنع نصف الخلافات في هذا القطاع. اجعلها رابطاً يفتحه العميل من جواله ويوافق فيه على بنود محددة، ويبقى السجل.
بماذا تبدأ
بالواحد الذي يُشكّل عملك الأساسي. وإن كان الاثنان معاً، ابنِ الورشة أولاً لأن تدفقها اليومي أكثف وأثر النظام فيها أسرع.
الفنادق والشقق المفروشة
الشيء المتبوع هو الليلة لا الحجز، وهذا هو الفرق الذي يخطئ فيه من بنى أنظمة حجز قبلاً.
المسار الحقيقي
بحث بتاريخين، فعرض توفّر وسعر يتغير بالموسم واليوم، فحجز بضمان أو دفع، فوصول، فإقامة قد تمتد أو تقصر، فخروج، فتنظيف وتجهيز الوحدة للضيف التالي.
الشاشات التي تهم
لوحة الوصول والخروج اليوم. وشاشة حالة الوحدات بالتنظيف والجهوزية، لأن غرفة نظيفة غير مسجّلة كنظيفة تعني ليلة فارغة. وشاشة التسعير بالموسم.
فخ نموذج البيانات
التوفّر يُحسب لكل ليلة على حدة لا لكل حجز. والسعر صفة على الليلة أيضاً، لأن إقامة خمس ليالٍ قد تحمل ثلاثة أسعار مختلفة. من يخزّن سعراً واحداً على الحجز لا يستطيع تمديد إقامة ولا تطبيق سعر موسم بشكل صحيح.
بماذا تبدأ
بالتوفّر والحجز والتسعير الموسمي ولوحة الوصول والخروج. التنظيف والتكامل مع منصات الحجز العالمية بعدها، والثاني مهم لكن لا تبدأ به قبل أن يكون توفّرك صحيحاً داخلياً.
الصيدليات وتجارة المستلزمات الطبية
الشيء المتبوع هو الدفعة لا المنتج، لأن تاريخ الانتهاء ورقم التشغيلة ليسا تفاصيل بل جوهر العمل.
المسار الحقيقي
شراء بدفعات لكل منها تاريخ انتهاء، فتخزين، فبيع يجب أن يصرف الأقرب انتهاءً أولاً، فمتابعة ما يقترب من الانتهاء لإرجاعه أو تصريفه، فإتلاف ما انتهى بسجل.
الشاشات التي تهم
شاشة ما ينتهي خلال تسعين يوماً مرتبة بالقيمة، لأنها تحوّل خسارة محتملة إلى قرار. وشاشة النواقص. وشاشة المرتجعات للمورّدين.
فخ نموذج البيانات
الرصيد ليس رقماً للمنتج بل مجموع أرصدة دفعاته. من يخزّن رصيداً واحداً للمنتج يفقد القدرة على معرفة ما ينتهي ومتى، وهي المعلومة الأهم في هذا القطاع. وهذا قرار لا يمكن إضافته لاحقاً بدون إعادة بناء المخزون كله.
بماذا تبدأ
بالمنتجات والدفعات وتواريخ الانتهاء والحركات. المشتريات والمرتجعات والتكامل مع نقاط البيع بعدها.
المصانع والإنتاج
الشيء المتبوع هو أمر الإنتاج، والفرق عن التجارة أن المخزون يتحوّل: مواد خام تدخل ومنتج تام يخرج بنسبة هدر.
المسار الحقيقي
طلب أو خطة إنتاج، فأمر إنتاج بكمية، فسحب مواد خام بحسب قائمة المكونات، فتشغيل بمراحل، فمنتج تام وهدر، فإدخال للمخزون، فتسليم.
الشاشات التي تهم
شاشة أوامر الإنتاج بمرحلتها. وشاشة قائمة المكونات لكل منتج. وشاشة تكلفة الوحدة الفعلية مقابل المعيارية، وهي التي تخبرك هل منتجك رابح فعلاً.
فخ نموذج البيانات
قائمة المكونات يجب أن تكون لها نسخ بتواريخ. تغيير مكوّن اليوم لا يجوز أن يغيّر تكلفة أوامر الإنتاج التي نُفّذت العام الماضي. والنظام الذي يحمل قائمة مكونات واحدة قابلة للتعديل يُنتج تاريخاً مالياً خاطئاً بهدوء.
بماذا تبدأ
بأوامر الإنتاج وقائمة المكونات وحركات المخزون. التكلفة الفعلية والجدولة وصيانة المعدات بعدها.
الطيران وخدمات السفر
قطاع عملت فيه لثلاثة عملاء، والدرس المشترك بينهم كان مفاجئاً: ما كانوا يحتاجونه لم يكن نظاماً جديداً.
الثلاثة جاءوا يطلبون مواقع جديدة بميزانيات إعادة بناء كاملة. وما وجدته عند فحص ما عندهم أن الهيكل تحت سليم، وأن المشكلة في العرض والسرعة والمحتوى لا في البنية. فخرجوا بنسخ محسّنة من مواقعهم بجزء من المبلغ المعروض عليهم.
وهذا هو القسم الذي أطلب من كل قارئ أن يتذكره: قبل أن تقرر بناء نظام جديد، اطلب من شخص كفؤ فحص ما عندك وإخبارك هل المشكلة في البنية أم في الاستخدام أم في العرض. الفحص يكلف جزءاً بسيطاً من البناء، وفي حالات كثيرة ينتهي بأن تنفق عشرة بالمئة لتحصل على ثمانين بالمئة من النتيجة.
وحين يكون النظام مطلوباً فعلاً في هذا القطاع، فالشيء المتبوع هو الطلب أو الاستفسار، والقيمة في سرعة الرد وتنظيم المتابعة، لأن عميل السفر يرسل نفس الاستفسار لثلاث شركات ويحجز مع أول من يرد برقم واضح.
التكاملات التي تهم في الخليج
أي نظام أعمال في هذه المنطقة يتكلم مع عدد محدود من الأنظمة الأخرى، والقرار الصحيح في كل واحد منها يوفّر أكثر من أي ميزة.
المحاسبة
السؤال الأول: هل تريد نظاماً واحداً يفعل كل شيء أم نظامين يتكلمان؟ جوابي في معظم الحالات الثاني. أنظمة المحاسبة المتخصصة تفعل المحاسبة أفضل من أي وحدة محاسبية مبنية داخل نظام تشغيلي، والمحاسب عندك يعرفها ولا يريد تعلّم غيرها.
والتكامل الصحيح ضيق ومحدد: نظامك التشغيلي ينتج القيود أو الفواتير ويرسلها، ولا يحاول أن يكون دفتر الأستاذ. وحدد اتجاه التدفق في البداية بوضوح، لأن المزامنة في الاتجاهين بين نظامين ماليين تنتج تعارضات لا يُحسم أي منها بشكل آلي.
الفاتورة الإلكترونية في السعودية
إن كان نظامك يصدر فواتير في السعودية فهذا ليس تكاملاً اختيارياً. الفاتورة تحتاج هيكلاً محدداً ورمز استجابة سريعة وإبلاغاً أو إجازة من هيئة الزكاة والضريبة والجمارك بحسب التزاماتك. وهي تمس نموذج البيانات نفسه، فأضفها في التصميم لا بعده. وتأكد من التزاماتك مع محاسبك أو مع الهيئة ثم أخبر المطور بما ينطبق.
المدفوعات
البوابة الإقليمية هي الافتراض الصحيح هنا لا العالمية، لأن مدى هي البطاقة التي يحملها معظم الناس في السعودية و Apple Pay يحوّل على الجوال أكثر من أي خيار آخر. وابدأ تسجيل التاجر في يوم بدء المشروع، فالأوراق والتحقق تستهلك أسابيع ولا علاقة لها بجاهزية الكود.
الرسائل وواتساب
الرسائل النصية موثوقة ومكلفة بالحجم. وواتساب أعلى قراءة بكثير في هذه المنطقة ويحتاج حساباً تجارياً وقوالب معتمدة مسبقاً للرسائل المبدوءة من جهتك. والقالب يحتاج موافقة، وهذا وقت على التقويم يجب أن يكون في الخطة.
والقاعدة العملية: استخدم واتساب للتذكيرات والتحديثات التي يقرأها العميل، والرسائل النصية لرموز التحقق، والبريد للمستندات والفواتير. وكل قناة تكلّف، فلا ترسل إلا ما يمكن التصرف بناءً عليه.
الموارد البشرية والرواتب
يُطلب غالباً كجزء من النظام وهو عادة قرار خاطئ. الرواتب فيها تفاصيل نظامية تتغير، والأنظمة المتخصصة تلاحقها. اربط ما تحتاجه فقط: الحضور، أو ساعات المشاريع، أو العمولات، وأرسلها إلى نظام الرواتب.
تبني أم تشتري؟
السؤال الذي يستحق وقتاً أطول مما يُعطى له. وهذا تقسيم عملي بحسب القطاع من واقع ما أوصي به العملاء فعلاً.
| القطاع | الأنسب عادة | السبب |
|---|---|---|
| المحاسبة والرواتب | اشترِ | متطلبات نظامية تتغير، والمتخصص يلاحقها بدلاً عنك |
| المتاجر الإلكترونية البسيطة | اشترِ | سلة وزد وشوبيفاي تغطي الحالة العادية وتنطلق أسرع بأسابيع |
| العقار والتطوير | ابنِ | مسار الحجز والدفعات والعمولات مختلف بين كل شركة وأخرى |
| العيادات | الاثنان | أنظمة عيادات جاهزة جيدة موجودة، والبناء يناسب من له مسار خاص أو عدة فروع بموارد مشتركة |
| المقاولات | ابنِ أو هجين | جدول الكميات والمستخلصات يتبع عقودك وطريقة عملك |
| المطاعم | الاثنان | نقاط البيع تُشترى، وقناة الطلب المملوكة تُبنى لتوفير العمولة |
| اللوجستيات | ابنِ | التسعير والمناطق وتسوية الدفع عند الاستلام خاصة بكل شركة |
| الحج والعمرة | ابنِ | تركيب الباقات وسلوك الشبكة في الموسم لا تغطيهما المنصات العامة |
| التدريب للأفراد | اشترِ | منصات التعلم الجاهزة كافية ورخيصة |
| التدريب المؤسسي | ابنِ | الشركة كمشترٍ والمجموعات وتقارير الموارد البشرية غائبة عن الجاهز |
والقاعدة التي تختصر الجدول: اشترِ ما هو عام، وابنِ ما يميّزك. وإن كان اعتراضك على المنصة الجاهزة شكلياً أو يخص خطوة مزعجة، تعايش معها سنة. وإن كان الاعتراض أنها تمنعك من طريقة عملك التي تربح منها، فابنِ.
وهناك خيار هجين أستخدمه كثيراً ويُغفل: اشترِ الأساس وابنِ الطبقة التي تخصك فوقه عبر واجهته البرمجية. متجر جاهز مع نظام مخصص للأسعار التعاقدية. نقاط بيع جاهزة مع لوحة تقارير مبنية لك. هذا يعطي أفضل النتيجتين ويخفض التكلفة والمخاطرة معاً.
كيف تجعل فريقك يستخدم النظام فعلاً
أكثر الأنظمة التي أُنقذها لم تكن مكسورة تقنياً، بل كان أحد لا يستخدمها. وهذا ليس مشكلة برمجية بل مشكلة إطلاق، وهي قابلة للحل.
اجلس مع من سيستخدمه قبل تصميمه
شاهد الشخص يؤدي العمل ساعة. لا تسأله كيف يعمل، لأنه سيصف العملية الرسمية. شاهده، وستجد الورقة الملصقة على الشاشة، والخطوة التي يتجاوزها دائماً، والحالة التي يعالجها بمكالمة. هذه هي المتطلبات التي لا تظهر في أي اجتماع.
اجعل الطريق الأسهل هو الطريق الصحيح
إن كان تسجيل البيانات في النظام أبطأ من كتابتها في دفتر، سيُستخدم الدفتر. قلّل الحقول الإجبارية إلى ما لا يمكن العمل بدونه، واجعل كل شيء آخر اختيارياً في البداية. يمكنك إجبار حقل لاحقاً بعد أن يصبح النظام عادة، ولا يمكنك إقناع فريق رفض النظام في الأسبوع الأول.
انقل بيانات حقيقية قبل اليوم الأول
النظام الفارغ يبدو عبئاً، والنظام الذي يفتحه الموظف فيجد فيه عملاءه ومشاريعه يبدو أداة. انقل ما تستطيع نقله من جداول إكسل قبل التسليم، حتى لو كان ناقصاً، فنقل ثمانين بالمئة من البيانات أفضل بكثير من بداية نظيفة.
عيّن شخصاً داخلياً مسؤولاً
شخص واحد في المنشأة يملك النظام، يجمع الملاحظات ويقرر الأولويات ويدرّب غيره. بدون هذا الشخص تصبح كل ملاحظة تذكرة مباشرة للمطور، فتتعارض الطلبات ويتوقف التحسين. والمشاريع التي عندها هذا الشخص تتصرف بشكل مختلف تماماً عن التي بلا.
أوقف الطريقة القديمة بتاريخ
التشغيل المتوازي بين النظام والطريقة القديمة يبدو حصيفاً وهو السبب الأشهر لفشل التبني. وجود طريقة احتياطية يعني أن أحداً لن يتعلم الجديدة. اختر تاريخاً، وشغّل بالتوازي أسبوعين للتحقق فقط، ثم أغلق القديم فعلاً.
الأرقام الخمسة التي يجب أن يراها المالك
معظم لوحات المعلومات فيها عشرون رقماً لا يُقرأ منها شيء. هذه الخمسة أضعها في كل نظام مهما كان القطاع، والباقي تحت الطلب.
- ما دخل وما خرج هذا الشهر، مقارناً بالشهر الماضي وبنفس الشهر العام الماضي
- ما هو مستحق ولم يُحصّل، مرتباً بالأقدم، لأن هذا أسرع مصدر نقد عندك
- حجم العمل القادم، أي الطلبات أو الحجوزات أو العقود المؤكدة التي لم تُنفّذ بعد
- الشيء الذي تأخر، أي عدد البنود المتجاوزة لوقتها، مهما كان البند في قطاعك
- مؤشر واحد خاص بقطاعك، مثل نسبة عدم الحضور للعيادة، أو نسبة الحل من الزيارة الأولى للصيانة، أو نسبة الحجز إلى البيع للعقار
والمقارنة هي ما يجعل الرقم مفيداً. رقم وحده لا يقول شيئاً، ورقم بجانب الشهر الماضي يقول كل شيء. اطلب أن يكون كل مؤشر في لوحتك مقارناً بشيء.
ترحيل بياناتك من جداول إكسل
بند يُقدَّر دائماً بأقل من حجمه ويؤخّر مشاريع أكثر من أي شيء آخر. وسببه أن جدول إكسل يسمح بما لا تسمح به قاعدة بيانات: خلية فيها رقمان، وتاريخ مكتوب بثلاث صيغ، وصف فارغ في المنتصف، وملاحظة مكتوبة في عمود السعر.
ما يحدث فعلاً
تُسلّم الجداول، فيُكتب برنامج يقرأها، فيرفض عشرين بالمئة من الصفوف لأسباب حقيقية، فيحتاج قراراً بشرياً في كل حالة. هل هذا العميل هو نفسه ذاك باختلاف كتابة الاسم؟ ما سعر هذا المنتج والخلية تحتوي "٢٥٠ أو ٣٠٠ حسب الكمية"؟ ما تاريخ هذا العقد والخلية تقول "بداية الشهر"؟
كيف تخفّض التكلفة
نظّف البيانات قبل التسليم، فهذا عمل يستطيع موظف عندك أداءه بتكلفة أقل من تكلفة مطور. وثبّت صيغة واحدة للتواريخ، وأزل الصفوف المدمجة والعناوين داخل البيانات، واجعل كل عمود يحمل نوعاً واحداً من القيم فقط، وأضف عموداً فيه معرّف فريد لكل سجل إن لم يكن موجوداً.
وقرار يوفّر كثيراً: لا تنقل كل شيء. البيانات التاريخية التي لن تُستخدم في عمل جاري يمكن أن تبقى في ملف مؤرشف. انقل العملاء النشطين والعقود السارية والأرصدة الحالية، واترك أرشيف خمس سنوات في مكانه. ويمكن إضافته لاحقاً إن احتجته، والغالب أنك لن تحتاجه.
البند الذي يجب أن يكون في العرض
اطلب أن يكون الترحيل بنداً مستقلاً بسعره، وأن يُنفّذ تجريبياً مرة قبل التسليم النهائي حتى ترى النتيجة وتصلح المصدر. والترحيل الذي يُنفّذ مرة واحدة في يوم الإطلاق هو مجازفة بلا سبب، لأنك ستكتشف المشاكل في أسوأ وقت.
الفروع المتعددة والشركات المتعددة
كلمتان تبدوان متشابهتين وتعنيان نظامين مختلفين في البنية، والخلط بينهما من أغلى الأخطاء في هذا المجال.
الفروع
شركة واحدة لها عدة مواقع. البيانات مشتركة والتقارير تُجمع على مستوى الشركة، والفرع صفة على العملية. هذا الأبسط، ويحتاج قرارات محددة: هل الأسعار موحدة أم لكل فرع سعره؟ هل المخزون منفصل أم مشترك مع تحويلات بينهما؟ هل يرى مدير الفرع فروعاً أخرى؟ أجب على الثلاثة قبل البناء، لأن كل واحد منها يمس نموذج البيانات.
الشركات المتعددة
كيانات مستقلة، لكل منها سجلها التجاري وحساباتها وفواتيرها، وقد تتعامل مع بعضها. هنا تصبح العزل مطلباً صارماً: بيانات شركة لا تظهر في أخرى، والتقرير المجمّع للمالك شيء منفصل يُبنى صراحة. وهذا أغلى بشكل محسوس من تعدد الفروع.
تعدد المستأجرين
الحالة الثالثة، وهي أن تبيع النظام نفسه لعملاء مختلفين من نشر واحد. هذه ليست ميزة تُضاف بل بنية تُقرر في الأسبوع الأول. كل استعلام في النظام يحمل قيداً بأن بيانات مستأجر لا تظهر في آخر، ويجب أن يصمد القيد في البحث والتقارير والتصدير وواجهة الجوال، بما يشمل المسارات التي تُضاف بعد سنة.
بنيت هذا في أومنيكستراك وفي كاسنتا، والدرس في الاثنين أن العزل هو المشروع وليس الميزات. والخطأ فيه مرة واحدة ليس عطلاً بل حادثة لا تتعافى منها المنشأة. فإن كنت تفكر في بيع نظامك لاحقاً كخدمة، قل هذا في أول اجتماع، لأن تحويل نظام أحادي الشركة إلى متعدد المستأجرين لاحقاً عمل يقارب إعادة البناء.
متى يحتاج فريقك تطبيق جوال
يُطلب التطبيق في معظم المشاريع ويحتاجه أقلها. والمعيار عندي واحد: هل يستخدم الشخص النظام وهو واقف أو متحرك أو خارج المكتب؟
المندوب والفني وموظف المخزون والمشرف في الموقع يحتاجون تطبيقاً، لأن أيديهم مشغولة وشبكتهم سيئة والشاشة صغيرة. وتطبيقهم يجب أن يفعل ثلاثة أشياء جيداً لا ثلاثين: يرى ما عليه، ويسجّل ما أنجزه، ويعمل عند انقطاع الاتصال.
أما المدير والمحاسب وموظف الاستقبال فلا يحتاجون تطبيقاً، بل موقعاً يعمل جيداً على الجوال. والفرق بينهما في التكلفة كبير وفي القيمة شبه معدوم لهذه الأدوار.
وحالة ثالثة يستحق فيها التطبيق: عميلك النهائي إن كان يستخدم الخدمة بتكرار عالٍ، كالتوصيل أو الحجز المتكرر. أما إن كان يستخدمها مرتين في السنة فالموقع أفضل، لأن أحداً لا يحمّل تطبيقاً لاستخدامه مرتين.
والعمل بدون اتصال هو البند الذي يجب أن يكون صريحاً في العرض إن كان مطلوباً، لأنه ليس إعداداً بل تصميم: ما يُحفظ محلياً، وكيف يُرسل لاحقاً، وما يحدث إن تعارض ما أرسله المندوب مع ما غيّره المشرف. قرار التعارض هذا هو العمل الحقيقي، وإغفاله ينتج تطبيقاً يفقد بيانات بهدوء.
كيف تصمم الصلاحيات بشكل صحيح
قسم تقني بلغة مشترٍ، لأن الصلاحيات هي أكثر ما يُنفَّذ بشكل خاطئ في الأنظمة المبنية بميزانيات صغيرة، والخطأ فيها لا يظهر حتى يظهر بشكل مكلف.
إخفاء الزر ليس صلاحية
أهم جملة في هذا القسم. الواجهة تخفي الزر، لكن إن كان الطلب الذي يُرسله الزر ما زال يعمل عند كتابة العنوان مباشرة، فأي شخص عنده حساب يستطيع تنفيذ العملية. الصلاحية تُفرض على الخادم في كل طلب، والواجهة تخفي فقط لتجميل التجربة.
اختبار تستطيع طلبه: اطلب من المطور أن يثبت أن مستخدماً بدور محدود لا يستطيع الوصول إلى بيانات دور أعلى حتى عند معرفة العنوان المباشر. هذا طلب مشروع ويجيب عليه من بنى بشكل صحيح في دقائق.
ثلاثة مستويات لا مستوى واحد
الصلاحية في أنظمة الأعمال ثلاثة أسئلة لا سؤال واحد. هل يستطيع هذا الدور رؤية هذه الشاشة؟ وهل يستطيع رؤية هذا السجل بالتحديد؟ وهل يستطيع تغيير هذا الحقل في السجل؟ والأنظمة البسيطة تجيب على الأول فقط، فتعطي موظفاً حق رؤية شاشة العملاء ثم يرى عملاء كل الفروع.
والمستوى الثالث يُغفل دائماً: مندوب المبيعات قد يرى الفاتورة ولا يجوز أن يعدّل السعر فيها. هذا ليس صلاحية شاشة بل صلاحية حقل، وهي شائعة الحاجة في المبيعات والمشتريات تحديداً.
ابدأ بالأقل ووسّع
التصميم الصحيح أن يكون الافتراضي هو المنع، ثم تُفتح الصلاحيات صراحة. والعكس، أن يكون الافتراضي السماح ثم تُمنع الحالات، يعني أن كل ميزة جديدة تُضاف بعد سنة تكون مفتوحة للجميع حتى يتذكر أحد تقييدها، وهذا لا يحدث.
النظام الذي لا يستخدمه أحد
أكثر من نصف الأنظمة التي أُعطيت لإنقاذها كانت تعمل تقنياً ولا تُستخدم. وهذه الأسباب مرتبة بترتيب تكرارها.
أبطأ من الطريقة القديمة
إدخال طلب يأخذ في النظام دقيقتين وفي الدفتر عشرين ثانية. المنطق واضح: الموظف سيختار الأسرع، ومن حقه. والإصلاح في الواجهة لا في الإقناع: قلّل الحقول، واحفظ آخر اختيار، واجعل البحث يعمل بالاسم الجزئي، وأضف اختصارات لوحة المفاتيح لمن يُدخل بيانات طول اليوم.
لا يتعامل مع الاستثناءات
الحالة التي يعالجها الموظف يومياً ليست في النظام، فيضطر للخروج منه لإنجازها، وبعد أسبوعين أصبح نصف العمل خارج النظام وبيانات النظام غير صحيحة. وهذا سببه أن الاستثناء لم يُسأل عنه في مرحلة المتطلبات.
يسأل عن بيانات لا تتوفر وقت الإدخال
حقل إجباري لا يعرف الموظف قيمته في اللحظة التي يُدخل فيها السجل. فيكتب أي شيء ليمر. وبعد شهر لديك عمود كامل بلا معنى. والإصلاح أن يكون الحقل اختيارياً في الإنشاء وإجبارياً في مرحلة لاحقة من المسار.
لا يعطي شيئاً لمن يُدخل
الموظف يُدخل والمدير يستفيد. هذا ترتيب لا يصمد. ابنِ شيئاً يستفيد منه المُدخل نفسه: قائمة مهامه، أو بحث يوفّر عليه مكالمة، أو تقرير عن أدائه، أو نموذج يُعبّأ آلياً بما أدخله سابقاً. أصغر فائدة مباشرة تغيّر سلوك الاستخدام كله.
تدريب مرة واحدة ثم لا شيء
جلسة تدريب في يوم التسليم تُنسى في أسبوع. والأفضل جلسة قصيرة في الأسبوع الأول، ثم جلسة ثانية بعد أسبوعين بعد أن تظهر الأسئلة الحقيقية، مع فيديو قصير لكل مهمة متكررة يرجع إليه الموظف الجديد. وتسجيل عشر مقاطع بثلاث دقائق أنفع من دليل بخمسين صفحة لا يُقرأ.
لماذا يصبح النظام بطيئاً بعد سنة
شكوى أسمعها كثيراً من أصحاب أنظمة بناها غيري: كان سريعاً في البداية وصار بطيئاً. والسبب في تسعين بالمئة من الحالات واحد، وهو ليس حجم الخادم.
السبب الحقيقي
الصفحة تطلب من قاعدة البيانات شيئاً داخل حلقة. أي أن صفحة فيها عشرة صفوف تنفّذ عشرة استعلامات، وفيها ألف صف تنفّذ ألف استعلام. في الاختبار ببيانات قليلة تعمل بشكل ممتاز، وفي السنة الثانية ببيانات حقيقية تنهار.
وهذا سبب أن ترقية الاستضافة لا تحل البطء عادة. الخادم الأسرع ينفّذ الألف استعلام أسرع قليلاً، والمشكلة أن العدد يجب أن يكون واحداً أو اثنين لا ألفاً. وهذا إصلاح في الكود يستغرق ساعات لمن يعرف ما يفعل.
السبب الثاني
غياب الفهارس على الأعمدة التي يُبحث بها. البحث بلا فهرس يقرأ كل السجلات في كل مرة. وهذا أيضاً إصلاح سريع وأثره فوري ومحسوس.
السبب الثالث
التقارير تُحسب من الصفر في كل مرة تُفتح. تقرير سنوي يجمع مليون سجل سيأخذ وقته دائماً. والحل أن تُحسب الأرقام المجمّعة دورياً وتُخزّن، فيصبح فتح التقرير قراءة لا حساباً.
ماذا تطلب
إن كان نظامك بطيئاً فلا تطلب خادماً أكبر أولاً. اطلب تحليل أداء يحدد أبطأ عشر صفحات وسبب كل واحدة. وهو عمل يُقاس بالأيام لا بالأسابيع، وفي كل مرة فعلته كان العائد أكبر من أي ترقية استضافة.
وإن كنت تبني نظاماً جديداً فاطلب بنداً صريحاً في العرض: اختبار أداء على حجم بيانات يشبه حجمك بعد سنتين لا حجمك يوم الإطلاق. رخيص عند طلبه مسبقاً، ومكلف عند اكتشافه لاحقاً.
الأمان في الأنظمة الداخلية
يُفترض أن النظام الداخلي أقل حاجة للأمان لأن مستخدميه معروفون. والعكس أصح في نقطة واحدة مهمة: النظام الداخلي يحمل كل بياناتك، لا جزءاً منها.
الحد الأدنى غير القابل للتفاوض
اتصال مشفّر، وكلمات مرور مخزّنة بشكل لا يسلّم الحسابات عند تسريب، وصلاحيات مفروضة على الخادم، وتعطيل فوري للحساب عند ترك الموظف، ونسخ احتياطية مجرَّبة. وهذا مشمول في أي بناء كفؤ ولا يجب أن يكون بنداً إضافياً.
ما يستحق الإضافة في الأنظمة الداخلية تحديداً
تحقق بخطوتين للحسابات الإدارية. وسجل من فعل ماذا على العمليات المالية وتعديل الأسعار وحذف السجلات. وتسجيل خروج آلي بعد مدة خمول، لأن أجهزة المكاتب تُترك مفتوحة. وتقييد التصدير، لأن أكبر خطر على بياناتك ليس اختراقاً بل موظف يصدّر قائمة العملاء كلها قبل أن يستقيل.
هذه الأخيرة نقطة يُغفلها الجميع وتستحق قراراً: من يستطيع تصدير بيانات، وهل يُسجّل التصدير، وهل هناك حد على عدد السجلات. وتسجيل التصدير وحده يغيّر السلوك.
عادة رخيصة
لا تدع بيانات حقيقية تجلس على جهاز مطور أو على بيئة تجريبية مفتوحة. النسخ المجهّلة للتطوير تكلّف شيئاً لا يُذكر وتزيل فئة كاملة من المخاطر لا علاقة لها بجودة الكود.
الذكاء الاصطناعي داخل أنظمة الأعمال
يُطلب في كل مشروع تقريباً هذه الأيام، والجواب الصادق أن معظم الطلبات يخدمها بحث جيد وتقرير واضح. أما ما يسدد ثمنه فعلاً فضيق ومحدد، وهذه الأشكال التي رأيتها تعمل.
ترتيب الطلبات الواردة
إذا كنت تستقبل عدداً كبيراً من الطلبات وتتابعها بالترتيب الزمني، فأنت تعالج طلباً صغيراً قبل طلب كبير. تصنيف الطلبات الواردة بحسب احتمال التحول وحجمها المتوقع يغيّر ترتيب عمل فريقك، وهو من أرخص الإضافات وأعلاها عائداً.
استخراج البيانات من مستندات
إن كان أحد في منشأتك يعيد كتابة أرقام من فواتير مورّدين أو كشوف أو عقود، فهذه مهمة مناسبة تماماً. والشرط الوحيد: المخرَج يُعرض للمراجعة قبل الحفظ، لا يُحفظ آلياً.
صياغة أول نسخة
عرض سعر، أو رد على استفسار متكرر، أو ملخص قضية أو مشروع. الصياغة الأولى تُنتج آلياً ويعتمدها إنسان. والترتيب لا يُقلب: الآلة تقترح والإنسان يوافق.
وهذا ما بنيته في سيجما بي إم أو، حيث يعمل التحليل آلياً على سبعة عشر مرحلة حوكمة ولا يصل شيء إلى بنك أو مستثمر قبل أن يعتمده شخص بالاسم. الترتيب المعاكس، أن تصل المخرجات آلياً، يشتري لك مسؤولية قانونية لا توفيراً.
وتكلفة التشغيل
استهلاك النماذج فاتورة مستمرة تنمو مع الاستخدام، بخلاف الاستضافة. اطلب تقديراً شهرياً على حجمك الحقيقي قبل الموافقة على أي ميزة ذكاء اصطناعي، فبعض الأفكار تبدو جيدة حتى يُحسب تشغيلها.
ما ينبغي أن يكون في عرض سعر أي نظام
عرض سعر نظام أعمال يختلف عن عرض موقع، وهذه البنود التي يجب أن أراها قبل أن أعتبر العرض جدياً.
- قائمة الأدوار وما يستطيع كل دور فعله
- حالات الشيء المتبوع وانتقالاتها، بما يشمل الرجوع للخلف
- التكاملات بالاسم، وهل تم التحقق من وجود واجهة برمجية لكل منها
- ترحيل البيانات كبند مستقل، بعد رؤية بياناتك الحالية
- الصلاحيات وسجل التدقيق صريحة، لا مؤجلة لمرحلة ثانية
- التقارير المشمولة بالاسم، وقابلية التصدير
- هل هناك تطبيق جوال، ولمن، وهل يعمل بدون اتصال
- التدريب والتوثيق والفيديوهات القصيرة
- مدة ضمان الأعطال بعد الإطلاق وتعريف العطل مقابل الطلب الجديد
- الصيانة السنوية وما تغطيه
- ملكية الكود، والحسابات التي ستكون باسم شركتك
- الاستثناءات صريحة
والبندان الأهم في القائمة هما ترحيل البيانات والاستثناءات. الأول لأنه أكثر بند يُسعَّر بأقل من حجمه فيتحول إلى خلاف. والثاني لأن المورّد الذي يكتب ما لن يفعله هو مورّد فكر في مشروعك فعلاً.
مثالان محسوبان من الصفر
التقسيم النظري يصل إلى حد معين. هذان مثالان أمرّ فيهما بالتمرين كله: ما يطلبه العميل، وما أوصي بتأجيله، والرقم في الحالتين.
مطور عقاري بمشروعين ومئة وخمسين وحدة
الطلب كما وصل: نظام كامل لإدارة المبيعات والعمولات والتسليم، وبوابة للعميل، وتطبيق جوال لفريق المبيعات، وتكامل مع المحاسبة، ولوحة معلومات للمالك.
| المكوّن | التقدير | رأيي |
|---|---|---|
| الأساس المشترك: أدوار وصلاحيات وسجل تدقيق | ٢٢٠٠ دولار | ضروري، لا يُؤجّل |
| مخزون الوحدات وحالاتها | ١٨٠٠ دولار | ضروري |
| الحجز بمدة وانتهاء آلي | ١٤٠٠ دولار | ضروري، وهو أكثر ما يحل مشكلة قائمة |
| العقود وجدول الدفعات والتحصيل | ٢٨٠٠ دولار | ضروري |
| العمولات واحتسابها | ١٦٠٠ دولار | مرحلة ثانية إلا إن كان الخلاف عليها قائماً الآن |
| التسليم ومحاضره وصوره | ١٥٠٠ دولار | مرحلة ثانية، لأن أول تسليم بعد أشهر |
| بوابة العميل | ٢٢٠٠ دولار | مرحلة ثانية، وقيمتها تقليل المكالمات لا البيع |
| تطبيق جوال لفريق المبيعات | ٤٥٠٠ دولار | أؤجّله. الفريق في المعرض أمام شاشة، وموقع يعمل على الجوال يكفي |
| تكامل المحاسبة | ١٨٠٠ دولار | مرحلة ثانية، باتجاه واحد فقط |
| لوحة معلومات المالك | ١٢٠٠ دولار | النسخة الأولى خمسة أرقام وتقرير أسبوعي بالبريد، بأربعمئة دولار |
| ترحيل البيانات من الجداول الحالية | ١١٠٠ دولار | ضروري، ومجرَّب مرة قبل التسليم |
الطلب الكامل نحو ٢٢١٠٠ دولار. والنسخة الأولى التي أوصي بها، وهي الأساس والمخزون والحجز والعقود والترحيل ولوحة مصغّرة، نحو ٩٧٠٠ دولار وتُسلّم في عشرة أسابيع بدل ثمانية عشر.
والسبب في التقسيم ليس السعر فقط. المشكلة التي تكلّف هذا العميل اليوم هي الحجوزات التي لا يحرّرها أحد والدفعات التي تتأخر بلا تنبيه. وهذان يُحلّان في النسخة الأولى. أما العمولات والتسليم والتطبيق فمشاكل سيواجهها بعد أشهر، وتصميمها بعد ثلاثة أشهر من استخدام النظام سيكون أفضل من تصميمها اليوم.
شركة صيانة مكيفات بثمانية فنيين
الطلب كما وصل: نظام لإدارة أوامر العمل والفنيين والمخزون وعقود الصيانة، مع تطبيق للفنيين وتطبيق للعملاء.
| المكوّن | التقدير | رأيي |
|---|---|---|
| الأساس المشترك | ٢٠٠٠ دولار | ضروري |
| أوامر العمل والزيارات كـكيانين منفصلين | ٢٤٠٠ دولار | ضروري، والفصل بينهما هو جوهر النظام |
| الجدولة بالمهارات والمناطق | ٢٢٠٠ دولار | ضروري |
| تطبيق الفني بقائمة فحص وصور وتوقيع | ٣٨٠٠ دولار | ضروري، وهذا القطاع يحتاجه فعلاً |
| العمل بدون اتصال في التطبيق | ١٤٠٠ دولار | ضروري، فالفنيون يعملون في أقبية وأسطح |
| المخزون وقطع الغيار | ٢١٠٠ دولار | مرحلة ثانية، والمتابعة بجدول إكسل تكفي ستة أشهر |
| عقود الصيانة واستهلاكها | ١٩٠٠ دولار | مرحلة ثانية إلا إن كانت أكثر من نصف الإيراد |
| الفوترة والدفع | ١٦٠٠ دولار | مرحلة ثانية |
| تطبيق للعملاء | ٤٢٠٠ دولار | أرفضه. العميل يطلب صيانة مرتين في السنة ولن يحمّل تطبيقاً |
| صفحة طلب صيانة وتتبع بالرابط | ٧٠٠ دولار | بديل تطبيق العملاء، ويؤدي نفس الغرض |
الطلب الكامل نحو ٢١٦٠٠ دولار. والنسخة الأولى، وهي الأساس وأوامر العمل والجدولة وتطبيق الفني بالعمل دون اتصال وصفحة الطلب، نحو ١٢٥٠٠ دولار في اثني عشر أسبوعاً.
ولاحظ الفرق بين المثالين في بند التطبيق. في العقار أجّلت تطبيق فريق المبيعات، وفي الصيانة اعتبرت تطبيق الفني ضرورياً وغير قابل للتأجيل. والمعيار واحد في الحالتين: هل يستخدم الشخص النظام وهو متحرك وبشبكة سيئة ويداه مشغولتان؟ موظف المعرض لا، والفني فوق سطح نعم.
وفي المثالين رفضت بنداً وأوصيت ببديل أرخص يؤدي الغرض. هذا هو السؤال الذي يستحق أن تطرحه على أي مورّد: ما البند الذي تقترح حذفه من طلبي، ولماذا؟ من يجيب يعمل لمصلحتك.
التقارير: ماذا تطلب بالتحديد
التقارير هي البند الذي يُكتب في العروض بسطر واحد ثم يُنفّذ بشكل لا يُستخدم. هذه الطريقة التي أوصي بطلبها بها.
اطلب التقرير كسؤال لا كاسم
"تقرير مبيعات" لا يعني شيئاً. أما "أي الفروع أعلى هامشاً هذا الربع؟" فسؤال، وهو يحدد للمطور ما يجب أن يُسجَّل في كل عملية ليكون الجواب ممكناً. اكتب من خمسة إلى عشرة أسئلة بهذه الصيغة، وستكون قد كتبت مواصفات التقارير كلها.
اطلب التصدير دائماً
كل تقرير قابل للتصدير إلى ملف. المحاسب سيطلب ملفاً، والمستثمر سيطلب ملفاً، والمدير سيريد تحليلاً في إكسل بطريقته. والتقرير الجميل على الشاشة بلا تصدير يعني أن أحداً سيعيد كتابته يدوياً، وهذا بالضبط ما بنيت النظام لتجنبه.
اطلب المقارنة في كل رقم
كل مؤشر مقارناً بالفترة السابقة وبنفس الفترة من العام الماضي. الرقم المفرد لا يُقرأ، والرقم المقارَن يُتصرف بناءً عليه. وهذه إضافة صغيرة في البناء وكبيرة في الاستخدام.
اطلب تقريراً يصل بدون أن تفتح النظام
ملخص يومي أو أسبوعي يصل بالبريد أو واتساب للمالك والمديرين. هذا أكثر تقرير سيُقرأ فعلاً في النظام كله، لأنه لا يحتاج فتح شيء. وتجربتي أن إضافته تغيّر علاقة المالك بالنظام أكثر من أي لوحة معلومات.
قاوم طلب لوحة المعلومات الكبيرة
اللوحة بعشرين مؤشراً تُفتح مرتين ثم تُنسى. خمسة أرقام مع مقارناتها، وزر يفتح التفصيل عند الحاجة، أنفع بكثير وأرخص في البناء.
هل تختار مورّداً يعرف قطاعك؟
سؤال يستحق جواباً مفصّلاً لأن الجواب البديهي ليس صحيحاً دائماً.
المورّد الذي بنى عشرة أنظمة في قطاعك يعرف الاستثناءات مسبقاً، وهذه قيمة حقيقية توفّر أسابيع من الاستكشاف. سيسألك عن حالات لم تفكر فيها لأنه رآها عند غيرك، وسيحذّرك من قرارات ندم عليها آخرون.
والجانب الآخر: قد يبني لك ما بناه للآخرين، ويفترض أن عملك مثل عملهم. وعملك فيه شيء يميّزه أو لم تكن لتبقى في السوق. فإن وجدت مورّداً خبيراً في قطاعك، فاختبره بسؤال واحد: ما الذي يختلف في حالتي عن الحالة التي تعرفها؟ من يجيب بتفصيل استمع إليك، ومن يقول إن كل الحالات متشابهة سيبيعك نظام غيرك.
والمورّد الذي لا يعرف قطاعك ليس بالضرورة خياراً أسوأ، بشرط أن يسأل كثيراً وأن يجلس مع فريقك ويشاهدهم يعملون. ومن خبرتي أن جودة الأسئلة أدق مؤشر من عدد المشاريع في نفس القطاع.
والترتيب الذي أنصح به: اختر على أساس الكفاءة والتواصل أولاً، والخبرة القطاعية ثانياً. مورّد كفؤ يتعلم قطاعك في أسبوعين، ومورّد يعرف قطاعك ولا يحسن البناء يسلّمك نظاماً يفهم عملك ولا يعمل.
ماذا يحدث عندما ينمو عملك ضعفين
السؤال الذي يجب أن تطرحه قبل البناء لا بعده، لأن جوابه يحدد قرارات لا يمكن تغييرها بسهولة.
ما ينمو بسهولة
عدد السجلات والمستخدمين في نظام مبني بشكل صحيح ينمو بلا مشكلة إلى أضعاف. وإضافة فرع أو نوع خدمة أو خطة سعر، إن كان النموذج يعبّر عن عملك، تكون إدخال بيانات لا تعديل كود.
ما لا ينمو
ثلاثة أشياء تحتاج قراراً معمارياً مبكراً، وتكلفتها بعد سنتين تقارب إعادة البناء. الأول عزل الكيانات إن قررت تحويل نظامك إلى خدمة تبيعها لآخرين. والثاني الصلاحيات على مستوى السجل إن كنت ستحتاج أن يرى كل مستخدم جزءاً من البيانات. والثالث تعدد العملات والكيانات القانونية إن كنت ستتوسع لبلد آخر.
فإن كان أي من الثلاثة احتمالاً وارداً في خطتك لثلاث سنوات، قله في أول اجتماع. تكلفة بناء الأساس صحيحاً من البداية صغيرة، وتكلفة إضافته لاحقاً كبيرة جداً.
العلامة التي تخبرك أن النظام لم يُبنَ للنمو
إن كان كل تغيير بسيط يحتاج مطوراً، فالنظام لم يُبنَ للنمو مهما قيل لك. الاختبار الذي أعطيه للعملاء: اطلب إضافة خدمة جديدة بسعر جديد، وأضف مستخدماً بصلاحيات مختلفة، وافتح فرعاً. إن احتاج أي من الثلاثة كوداً، فأنت تملك نظاماً يصف وضعك لا نظاماً يدير عملك.
عشرة أسئلة تطرحها على نفسك قبل أي نظام
هذه القائمة تختصر المقال كله، وجوابك عليها هو نصف المشروع.
- ما الشيء الواحد الذي سيتبعه النظام؟
- ما حالاته، ومن يملك كل انتقال، وما يحدث عند الرجوع للخلف؟
- من يستخدمه، وما لا يجوز أن يفعله كل دور؟
- ما أصعب ثلاث حالات في عملك، وهل تمر في النظام أم حوله؟
- أي الأسئلة تريد أن يجيب عليها آخر الشهر، وهل تُسجَّل البيانات اللازمة لذلك؟
- مع أي أنظمة يجب أن يتكلم، وهل لها واجهات برمجية فعلاً؟
- من سيملكه داخلياً، وهل هو متفرغ؟
- ما أقل نسخة تستطيع تشغيل عملك بها؟
- هل أحتاج تطبيق جوال لأحد، أو مجرد موقع يعمل على الجوال؟
- هل أخطط لبيع هذا النظام لآخرين أو للتوسع لبلد ثانٍ خلال ثلاث سنوات؟
السؤال الثامن هو الأهم وأكثر ما يُهمَل. أقل نسخة قابلة للتشغيل ليست نسخة ناقصة بل هي الاستراتيجية الصحيحة، لأنها تبدأ بالعائد قبل اكتمال المشروع وتمنحك ثلاثة أشهر من الأدلة قبل أن تقرر المرحلة الثانية.
الخيط المشترك بين كل القطاعات
ما يجمع كل القطاعات في هذا المقال شيء واحد: النظام الناجح ليس الذي فيه ميزات أكثر، بل الذي يفهم الشيء الذي تتبعه وحالاته واستثناءاته. هذا الفهم لا يأتي من عرض تجريبي ولا من قائمة ميزات، بل من ساعة تجلس فيها مع من يؤدي العمل، وصفحتين تكتبهما قبل أن تكلّم أي مطور.
ولهذا يفشل النظام المبني على قائمة ميزات وينجح النظام المبني على مسار. القائمة تخبر المطور بما يضيفه، والمسار يخبره بما يجب أن يصمد. والفرق يظهر في الشهر الثالث لا في العرض التجريبي.
وما تبقى في هذا المقال هو الجانب العملي: كم تكلف هذه الأنظمة، وكيف تكتب متطلباتك في صفحتين، وكيف تبدأ في تسعين يوماً.
كيف تقيس هل النظام نجح
معظم المنشآت لا تقيس، فتُحكم على النظام بالإحساس: هل الناس يشتكون أم لا. وهذا مقياس سيئ لأن الشكوى تأتي من التغيير نفسه لا من النظام. هذه أربعة مقاييس تستطيع قراءتها بعد ثلاثة أشهر بدقة.
نسبة العمل الذي يمر داخل النظام
أهم مقياس وأكثره إهمالاً. خذ عدد العمليات التي سُجّلت في النظام هذا الشهر واقسمها على عددها الحقيقي الذي تعرفه من حساباتك. إن كانت النسبة تحت ثمانين بالمئة فجزء من عملك يحدث خارج النظام، وبياناتك غير صحيحة، وكل تقرير تبنيه عليها مضلّل.
والنسبة المنخفضة ليست مشكلة في الالتزام بل إشارة على أن النظام لا يتعامل مع حالة حقيقية. اسأل أين تُسجَّل العمليات الناقصة ولماذا، وستجد الاستثناء الذي لم يُسأل عنه في البداية.
الساعات التي تحررت
قس نفس الشيء الذي قستَه قبل البناء: كم ساعة أسبوعياً تستهلكها العملية التي استبدلتها. وإن لم تكن قستَها قبل البناء فلن تستطيع إثبات شيء، وهذا سبب أن أطلب القياس قبل البدء لا بعده.
عدد المرات التي يُطلب فيها رقم بالبريد
مؤشر غير مباشر وصادق جداً. إن كان المالك ما زال يطلب أرقاماً من الموظفين بالبريد أو واتساب، فالتقارير لم تنجح، وإن كان يفتح النظام أو يقرأ الملخص الأسبوعي فقد نجحت.
الأخطاء التي توقفت
اكتب قبل البناء الأخطاء التي تكلفك مالاً وتتكرر: الحجز المزدوج، أو الطلب الذي لا يتابعه أحد، أو الفاتورة التي تُنسى، أو الموعد النظامي الذي يفوت. وبعد ثلاثة أشهر عُدّها. وهذا أوضح دليل على العائد وأسهل ما يمكن حسابه بالمال.
وماذا تفعل بالنتيجة
المقاييس الأربعة تحدد المرحلة الثانية أدق من أي خطة. إن كانت نسبة العمل داخل النظام منخفضة فالمرحلة الثانية هي تغطية الاستثناءات لا إضافة ميزات. وإن كانت عالية والساعات تحررت فالمرحلة الثانية هي المسار التالي الذي يستهلك وقتاً. وإن كان المالك ما زال يسأل بالبريد فالمرحلة الثانية تقارير لا شيء آخر.
وهذا هو الفرق بين منشأة تبني نظاماً مرة وتتركه يتعفن، ومنشأة يصبح نظامها أصلاً ينمو معها. الأولى تقرر المرحلة الثانية بالإحساس، والثانية تقررها بأربعة أرقام تجمعها في ساعة.
ثلاث حالات لا تبنِ فيها نظاماً
أنهي بهذا لأنه سيوفّر على بعض القراء أكثر من كل ما سبق.
الأولى: عمليتك نفسها غير مستقرة وتتغير كل شهر. برمجة عملية مرتبكة تثبّت الارتباك وتجعل تغييره أغلى. نظّمها على ورق أو في جدول حتى تستقر ثلاثة أشهر، ثم ابنِها. والنظام يسرّع عملية قائمة ولا يصنع واحدة.
الثانية: الشخص الذي سيملك النظام داخلياً غير موجود أو غير متفرغ الشهرين القادمين. المشروع سيتمايل وستدفع ثمن التمايل في صورة قرارات متأخرة ونطاق ينمو بلا اتجاه. أجّله حتى يتفرغ.
الثالثة: منصة جاهزة تؤدي العمل واعتراضك عليها شكلي أو يخص خطوة مزعجة. تعايش معها سنة، وأنفق الفرق على ما يجلب لك عملاء. وبعد سنة ستعرف بدقة ما تمنعك المنصة من فعله، وستكون قد اشتريت معرفة بثمن الاشتراك بدل أن تشتري نظاماً على تخمين.
والمشاريع التي تنجح عندي تشترك في صفة واحدة: شخص في المنشأة احتاج الشيء بدرجة كافية ليتخذ القرارات بسرعة. وعندما لا يوجد هذا الشخص بعد، الانتظار أرخص من البدء.
التكلفة والمدة لكل نوع نظام
أرقام عملية بالدولار من مشاريع سلّمتها، على افتراض بريف واضح ومتخذ قرار واحد. وهي للنسخة الأولى القابلة للتشغيل لا للنظام الكامل بكل مراحله.
| النظام | النسخة الأولى | المدة | ما يرفع الرقم |
|---|---|---|---|
| إدارة علاقات العملاء والطلبات | من ٤٠٠٠ إلى ١٢٠٠٠ | من ٦ إلى ١٢ أسبوعاً | تعدد المستأجرين، والتكامل مع المحاسبة |
| حجز ومواعيد | من ٤٠٠٠ إلى ٢٠٠٠٠ | من ٥ إلى ١٢ أسبوعاً | موارد متعددة، والدفع، وعدة فروع |
| مخزون وتجزئة | من ٦٠٠٠ إلى ٢٥٠٠٠ | من ٨ إلى ١٦ أسبوعاً | الفروع، والمتغيرات، وربط قنوات البيع |
| عقار ومخزون وحدات | من ٨٠٠٠ إلى ٣٠٠٠٠ | من ٨ إلى ١٨ أسبوعاً | العمولات، والتسليم، وبوابة العميل |
| مقاولات ومستخلصات | من ١٠٠٠٠ إلى ٣٥٠٠٠ | من ١٠ إلى ٢٠ أسبوعاً | التكلفة الفعلية، والمقاولون من الباطن |
| لوجستيات وتوصيل | من ١٠٠٠٠ إلى ٤٠٠٠٠ | من ١٠ إلى ٢٠ أسبوعاً | تطبيق المندوب، والدفع عند الاستلام، والتتبع المباشر |
| إدارة قضايا قانونية | من ٥٠٠٠ إلى ١٨٠٠٠ | من ٦ إلى ١٤ أسبوعاً | الفوترة بالساعة، وصلاحيات على مستوى السجل |
| تدريب مؤسسي | من ٦٠٠٠ إلى ٣٠٠٠٠ | من ٨ إلى ١٨ أسبوعاً | طبقة الشركات، والتقييم، والشهادات |
| خدمات ميدانية وصيانة | من ٧٠٠٠ إلى ٢٥٠٠٠ | من ٨ إلى ١٦ أسبوعاً | تطبيق الفني، والمخزون، وعقود الصيانة |
وثلاث ملاحظات على كل سطر في الجدول. الأول أن تطبيق الجوال للفريق الميداني ليس بنداً صغيراً ويضيف عادة ما بين ٣٠ و٥٠ بالمئة. والثاني أن الترحيل من بياناتك الحالية بند مستقل يُقدَّر بعد رؤية الجداول. والثالث أن الصيانة السنوية من ١٠ إلى ٢٠ بالمئة من تكلفة البناء، وأعلى للأنظمة ذات التكاملات الكثيرة.
كيف تكتب متطلبات نظامك في صفحتين
هذا المستند هو أرخص شيء تفعله وأكبر أثر على ما ستحصل عليه. وأعطي هنا الهيكل بالضبط حتى تكتبه بنفسك قبل أن تتحدث مع أي مطور.
الصفحة الأولى
سطران عن المشكلة بصيغة ما يحدث اليوم وما يكلفه. ثم جملة واحدة عن الشيء الذي سيتبعه النظام. ثم قائمة الأدوار، وتحت كل دور من ثلاثة إلى خمسة أشياء يفعلها وشيء واحد لا يجوز أن يفعله. ثم قائمة حالات الشيء المتبوع بترتيبها، ومن يملك كل انتقال، وما يحدث عند الرجوع للخلف.
الصفحة الثانية
الأنظمة التي يجب أن يتكلم معها بالاسم، وهل لها واجهة برمجية، وهل عندك بيانات الدخول. ثم الأرقام التي تريد رؤيتها آخر الشهر، مكتوبة كأسئلة. ثم حجمك الحقيقي: كم مستخدماً، وكم عملية شهرياً، وكم فرعاً. ثم القيود: نطاق الميزانية، والتاريخ المطلوب وسببه، ومن يوافق.
ملحق اختياري يغيّر العرض
صفحة ثالثة فيها أصعب ثلاث حالات في عملك موصوفة كقصص. "عميل حجز وحدة ودفع نصف المبلغ ثم طلب تحويل الحجز لأخيه" أنفع لمطور من عشرين سطر مواصفات. وهي أيضاً الطريقة التي تكشف بها بسرعة من فهم مشكلتك ومن لم يفهمها.
خطة تسعين يوماً من الصفر
إن قررت البدء، هذا الترتيب الذي أوصي به، وهو مبني على أن العائد يبدأ قبل اكتمال النظام.
الأسبوعان الأول والثاني
اكتب مستند الصفحتين. اجلس مع من سيستخدم النظام وشاهده يعمل. نظّف بياناتك الحالية في جداول إكسل. ابدأ أي تسجيل خارجي يحتاج وقتاً، كبوابة الدفع أو حساب واتساب التجاري، لأن هذه تستهلك أسابيع ولا علاقة لها بالبرمجة.
من الثالث إلى السادس
اختر المورّد واتفق على نطاق مكتوب بالاستثناءات. وابدأ ببناء الأساس المشترك والمسار الواحد الذي يستهلك أكبر عدد ساعات في عملك. وفي نهاية هذه الفترة يجب أن يكون عندك شيء تستطيع فتحه وإدخال بيانات حقيقية فيه، ولو كان ناقصاً.
من السابع إلى العاشر
أكمل المسار الأول، وأضف التقارير الخمسة الأساسية، ورحّل بياناتك تجريبياً وراجع النتيجة وأصلح المصدر. ودرّب شخصاً داخلياً ليكون مالك النظام.
من الحادي عشر إلى الثالث عشر
شغّل بالتوازي أسبوعين للتحقق فقط، ثم أوقف الطريقة القديمة بتاريخ محدد. واحتفظ بأسبوعين من وقت المطور للشهر الذي يلي الإطلاق، فهذه أعلى عائد في المشروع كله.
وما بعد التسعين يوماً: راقب أين يرجع الموظفون إلى الطريقة القديمة، فهذه الإشارة تخبرك بما ينقص النظام أدق من أي خطة تطوير كتبتها في البداية. والمرحلة الثانية المصممة على ثلاثة أشهر من الاستخدام الحقيقي مشروع أفضل بكثير من مرحلة ثانية خُطّطت في اليوم الأول.
ثلاثة أخطاء تكلّف أكثر من أي قرار تقني
بناء كل شيء مرة واحدة
النظام الذي يُطلق كاملاً بعد تسعة أشهر يحمل تسعة أشهر من افتراضات لم تُختبر. والنظام الذي يُطلق ناقصاً بعد شهرين يبدأ في تصحيح نفسه فوراً. اختر الثاني دائماً، وليس لأنه أرخص بل لأنه ينتهي بنظام أفضل.
نسخ نظام منافس
طلب يأتيني كثيراً: ابنِ لي مثل نظام فلان. والمشكلة أن نظام فلان مبني على عمليته هو، وفيها قرارات لا تراها من الخارج ولا تناسبك. انسخ ما تفهم سببه، واسأل عن الباقي.
تأجيل الصلاحيات والسجل للمرحلة الثانية
أسوأ تأجيل ممكن. الأدوار والصلاحيات وسجل من فعل ماذا بنية لا ميزات، وإضافتها بعد سنة من التشغيل عمل يقارب إعادة البناء. أما إضافة تقرير أو شاشة فسهلة في أي وقت. فإن اضطررت للاقتطاع، اقتطع من الميزات لا من البنية.
من أين تبدأ عملياً
إن كان عندك قطاع من القطاعات أعلاه وتفكر في نظام، فأقصر طريق إلى رقم وخطة هو التالي: اكتب مستند الصفحتين، وأضف أصعب ثلاث حالات عندك، وأرسل معه حجمك الحقيقي ونطاق ميزانيتك.
أرد بتقدير، وبما أراه النسخة الأولى الصحيحة، وبما أوصي بتأجيله. وفي الحالات التي يكون الجواب فيها أن تشتري منصة جاهزة بدل أن تستأجرني، أقولها، لأن نظاماً لا تحتاجه أسوأ لي منه لك.
وإن كان عندك نظام بالفعل وتفكر في استبداله، فابدأ بفحص قبل أي قرار. الفحص يحدد هل المشكلة في البنية أم في الاستخدام أم في الأداء، وهو يكلف جزءاً بسيطاً من إعادة البناء. وفي حالات كثيرة ينتهي بأن تنفق عشرة بالمئة لتحصل على ثمانين بالمئة من النتيجة التي كنت ستشتريها بإعادة بناء كاملة. فعلت هذا لثلاثة عملاء في قطاع الطيران، وخرج الثلاثة بأنظمة محسّنة لا جديدة.
وإن كنت في مرحلة أبعد من ذلك، أي عندك نظام يعمل وتريد المرحلة الثانية، فأرسل معه الأرقام الأربعة من قسم القياس. نسبة العمل الذي يمر داخل النظام تحدّد المرحلة الثانية أدق من أي قائمة أمنيات، وهي معلومة تجمعها في ساعة.