نظام طلبات الشراء الداخلية: تجنب الاختناقات

لماذا تتعطل طلبات الشراء

تبدأ معظم تأخيرات الشراء قبل أن يوافق أحد على الطلب أو يرفضه. يطلب موظف حاسوبًا محمولًا عبر البريد الإلكتروني، وينشر السعر في المحادثة، ثم يضيف صفًا في جدول بيانات للمالية. كل مكان يحتوي على جزء من الطلب، لذلك يتعين على المشتري جمع المورد والتكلفة وسبب الشراء ومالك الميزانية والموعد النهائي.

هذا يخلق عملًا مكررًا. يطلب المدير تفاصيل سبق أن أرسلها الموظف إلى المالية. تفحص المالية الميزانية، لكنها لا تعرف ما إذا كان رئيس القسم قد وافق على الحاجة. ولا يستطيع الموظف معرفة مكان الطلب أو الشخص الذي يجب أن يتصرف بعد ذلك.

التفاصيل الناقصة تسبب التأخير

يتباطأ سير عمل الموافقة على الشراء عندما لا يحتوي الطلب على المعلومات التي يحتاجها كل شخص. ومن الفجوات الشائعة:

• عدم وجود وصف للعنصر أو الكمية أو عرض سعر من المورد
• عدم وجود قسم أو مركز تكلفة أو مبلغ للميزانية
• عدم وجود سبب تجاري أو تاريخ التسليم المطلوب
• عدم تحديد مسؤول الموافقة أو مسؤول الشراء
• عدم وجود سجل للتعليقات أو التغييرات أو القرارات السابقة

قد يؤدي نقص واحد إلى إعادة الطلب إلى البداية. فقد يوافق قائد الفريق على تجديد برنامج بقيمة 1,200 دولار، ثم تكتشف المالية أن أحدًا لم يحدد الميزانية. وبدلًا من تقديم الطلب، يقضي الفريق أيامًا في البحث عن الشخص المسؤول عن هذا الإنفاق.

سجل واحد وملكية واضحة

يحافظ نظام طلبات الشراء الداخلية على الطلب كاملًا من الإرسال حتى تسليم طلب الشراء. يُدخل مقدم الطلب الحاجة مرة واحدة. ويرى المديرون وموظفو المالية والمشترون التفاصيل نفسها، ويضيفون التعليقات إلى السجل نفسه، ويتركون سجلًا واضحًا للقرارات.

تقلل تسميات الحالة الواضحة من المتابعات غير الضرورية. يمكن أن يوضح الطلب ما إذا كان يحتاج إلى مراجعة الميزانية أو موافقة المدير أو إجراء المشتري أو تفاصيل المورد. وتحتاج كل مرحلة إلى شخص أو دور محدد، إضافة إلى قاعدة بديلة عند الغياب.

يجعل تطبيق المشتريات من دون برمجة هذا الأمر عمليًا، من دون أن تضطر فرق العمليات إلى إدارة النماذج وجداول البيانات. يستطيع AppMaster دعم نماذج الطلبات وحقول الميزانية ومنطق الموافقة وقائمة انتظار للمشترين في تطبيق واحد. يجب أن يكون لكل طلب مكان واحد ومالك حالي وتفاصيل كافية ليتقدم نحو إصدار الطلب.

حدّد ما يجب أن يتضمنه كل طلب

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

يحتاج كل طلب إلى اسم العنصر والكمية والمورد والتكلفة التقديرية للوحدة والتكلفة الإجمالية وسبب الشراء. أضف القسم ومركز التكلفة ومقدم الطلب وتاريخ الحاجة عندما تؤثر هذه التفاصيل في الميزانية أو التسليم. وبعد تسجيل دخول الموظف، يمكن للنظام ملء اسمه وقسمه تلقائيًا.

يعمل السبب المختصر أفضل من مربع نص كبير وفارغ. مثلًا: «خمس تراخيص إضافية لفريق دعم العملاء في الوردية المسائية الجديدة». يمنح ذلك الموافق سببًا عمليًا وكمية ورابطًا بالعمل الحالي.

استخدم نوعين من الطلبات

تحتاج مشتريات الكتالوج والمشتريات الفردية إلى نماذج مختلفة. يحتوي عنصر الكتالوج مسبقًا على وصف معتمد ومورد وسعر، وأحيانًا مرجع للعقد. يختاره الموظفون ويدخلون الكمية ويشرحون الحاجة، وهذا يحافظ على اتساق الطلبات الشائعة.

أما الشراء الفردي فيحتاج إلى مزيد من السياق، لأن المشتريات يجب أن تقيّمه قبل تقديم الطلب. اطلب وصف العنصر أو الخدمة، والمورد المفضل وبيانات الاتصال به إن كانت معروفة، وعرض السعر أو التكلفة التقديرية، والكمية وتكرار الفوترة، وسبب الشراء، وتاريخ التسليم المطلوب.

لا تجبر الموظفين على العثور على مورد قبل طلب شيء ما. قد يعرف الموظف أنه يحتاج إلى مكتب قابل للوقوف من دون معرفة المورد الذي يلتزم بقواعد الشركة. يمكن للمشتريات إكمال هذا الجزء لاحقًا.

اجعل الحقول المطلوبة مبررة

اجعل الحقل إلزاميًا فقط عندما يحتاجه شخص للموافقة على الطلب أو وضع ميزانيته أو شرائه. وعادةً ما تنتمي العناصر والكمية والتكلفة التقديرية ومركز التكلفة والسبب إلى هذه المجموعة. لا تجعل المرفقات إلزامية إلا فوق حد إنفاق معين أو لفئات مثل اشتراكات البرامج.

تجعل الحقول المشروطة النموذج أسهل في الاستخدام. يمكن لطلب برنامج أن يسأل عن عدد المستخدمين وتاريخ التجديد وما إذا كان سيتعامل مع بيانات العملاء. ويمكن لطلب عنصر مادي أن يسأل عن عنوان التسليم بدلًا من ذلك. هكذا يحصل كل مسار موافقة على الحقائق التي يحتاجها، من دون إجبار كل موظف على ملء نموذج طويل.

قبل الإطلاق، أرسل ثلاثة طلبات تجريبية: عنصرًا من الكتالوج، وشراءً من مورد جديد، وخدمة متكررة. إذا ظل الموافق يطرح سؤالًا واضحًا، فأضف حقلًا أو اجعل حقلًا موجودًا أكثر وضوحًا.

أنشئ كتالوجًا يسرّع الطلبات

يزيل الكتالوج العمل المتكرر. فبدل أن يصف كل موظف حاسوبًا محمولًا أو ترخيص برنامج أو كرسي مكتب من الصفر، امنحه قائمة قصيرة من الخيارات المعتمدة.

يجب أن يتضمن كل عنصر في الكتالوج وصفًا واضحًا وسعر الوحدة المعتاد والمورد المفضل. أضف تفاصيل تمنع رسائل المتابعة، مثل رمز العنصر أو مدة العقد أو المقاسات المتاحة أو ما إذا كان المدير يجب أن يؤكد الحاجة.

قد يتضمن عنصر «حاسوب محمول قياسي» الطراز والمورد المعتمد والسعر البالغ 1,200 دولار وضمانًا لمدة ثلاث سنوات. يختار مقدم الطلب الكمية ويشرح من سيستخدمه. وتحصل المشتريات في كل مرة على المعلومات المفيدة نفسها.

أبقِ الخيارات بسيطة

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

قسّم العناصر إلى فئات مألوفة، مثل البرامج والمعدات واللوازم المكتبية والخدمات المهنية. استخدم البحث والأسماء القصيرة حتى يجد الناس العنصر قبل أن يبدأوا في كتابة الوصف.

يحتاج عنصر الكتالوج عادةً إلى اسم العنصر ووصفه وسعر الوحدة أو النطاق المتوقع والمورد المفضل ووحدة الفوترة وأي قيود. مثلًا، قد يظهر الاشتراك بصيغة «لكل مستخدم، لكل شهر»، مع توضيح أن موافقة المدير مطلوبة.

اترك مجالًا للاستثناءات

سيحتاج الموظفون أحيانًا إلى شيء غير مدرج. أبقِ خيار الطلب الحر، لكن اطلب معلومات كافية لبدء الخطوة التالية: الحاجة والتكلفة التقديرية والمورد إن كان معروفًا وسبب الشراء.

تعامل مع الطلبات الحرة كقائمة مراجعة، لا كفشل للكتالوج. يمكن للمشتريات مقارنة عروض الأسعار أو اعتماد مورد أو إضافة العنصر إلى الكتالوج للطلبات المستقبلية.

في تطبيق مشتريات من دون برمجة مبني باستخدام AppMaster، يمكن لاختيار عنصر من الكتالوج أن يملأ السعر والمورد وحقول الطلب تلقائيًا. يمنح ذلك عملية اعتماد الميزانية بيانات أنظف ويقلل أعمال التصحيح قبل تسليم طلب الشراء.

أضف فحوصات الميزانية قبل الموافقة

يجب أن يظهر السياق المالي للطلب قبل أن يبدأ أي شخص مهمة الموافقة. اطلب من مقدم الطلب اختيار قسم ومركز تكلفة، ثم سجّل المبلغ والعملة. ويمكن للنظام استخدام هذه الحقول للعثور على الميزانية المناسبة.

اجعل الفحص بسيطًا لمقدم الطلب. يجب أن يرى إجمالي الطلب والميزانية المتاحة والمبلغ الذي سيبقى بعد الموافقة. تمنع رسالة مثل «يتجاوز هذا الطلب الميزانية المتبقية بمقدار 420 دولارًا» المدير من اكتشاف المشكلة لاحقًا في سلسلة بريد إلكتروني.

تحتاج المالية إلى امتلاك أرقام الميزانية. ويمكن للموظفين تحديث المبلغ المعتمد لكل قسم أو مركز تكلفة في بداية الفترة وتعديله عند تغير الخطط. يجب أن يتتبع نظام طلبات الشراء الداخلية أيضًا الطلبات المعتمدة التي لم تتحول بعد إلى فواتير، وإلا فقد يبدو أن لدى الفريق أموالًا متبقية رغم التزامه بها بالفعل.

افحص إجمالي الطلب بالكامل

احسب ما ستدفعه المشتريات فعليًا. أدرج الكميات وأسعار الوحدات والضرائب والشحن ورسوم الإعداد والتكاليف المتكررة عند انطباقها. اشتراك برنامج بقيمة 900 دولار مع رسوم تنفيذ قدرها 150 دولارًا هو طلب بقيمة 1,050 دولارًا.

شغّل عملية اعتماد الميزانية عندما يرسل مقدم الطلب النموذج، وقبل أن يرسله النظام إلى الموافق. فهذا يمنع إهدار وقت المراجعة ويتيح لمقدم الطلب تصحيح مركز التكلفة أو تقليل الطلب أو شرح الاستثناء.

في تطبيق مشتريات من دون برمجة، يمكن تنفيذ ذلك كقاعدة مرئية: اقرأ مركز التكلفة المختار، وقارن إجمالي الطلب بالميزانية المتبقية، ثم احفظ النتيجة في الطلب. يستطيع AppMaster نمذجة بيانات الطلب وإنشاء المنطق في Business Process Editor وعرض النتيجة في نموذج داخلي.

حدّد مسار الطلبات التي تتجاوز الميزانية

لا تترك طلبًا يتجاوز الميزانية في حالة غير واضحة. امنحه مسارًا محددًا يتوافق مع سياسة الإنفاق. يمكنك إعادته إلى مقدم الطلب مع إظهار الفرق، أو إرساله إلى مالك الميزانية للحصول على استثناء، أو إرسال الحاجة العاجلة إلى المالية، أو تعليقها حتى فترة الميزانية التالية مع تحديد التاريخ والسبب.

سجّل نتيجة الميزانية وأي قرار بشأن الاستثناء. عندما تبدأ المشتريات الطلب، يستطيع الموظفون معرفة ما إذا كان الإنفاق يتوافق مع الميزانية الأصلية ومن وافق على المبلغ الإضافي. كما يمكن للمالية تفسير سبب تجاوز مركز التكلفة للخطة.

ضع مسارات موافقة يمكن للجميع اتباعها

يحتاج نظام طلبات الشراء الداخلية إلى قواعد توجيه قبل أن يرسل أي شخص طلبًا. أرسل كل طلب إلى أشخاص يستطيعون تقييم الإنفاق، بدلًا من صندوق بريد عام لا يراجعه أحد إلا أحيانًا.

ابنِ المسار على المعلومات التي جُمعت في النموذج. يوفر القسم ومركز التكلفة وفئة الشراء والمبلغ الإجمالي عادةً سياقًا كافيًا. قد يحتاج طلب لوازم مكتبية بقيمة 40 دولارًا إلى مدير الفريق فقط، بينما قد يتطلب عقد برنامج جديد موافقة مالك الميزانية وتقنية المعلومات والأمن والمشتريات.

أبقِ المسارات قصيرة عندما تكون المخاطر منخفضة. فإضافة موافقين «احتياطًا» تحول سير عمل الموافقة البسيط إلى سلسلة من التأخيرات. يجب أن يكون لدى كل موافق سبب واضح للموافقة أو الرفض أو طلب مزيد من المعلومات.

استخدم قواعد يمكن توقعها

يجب أن يعرف الموظفون إلى أين سيتجه طلبهم قبل إرساله. كما تقلل القواعد المتوقعة الخلافات عندما يتعطل الطلب.

مثلًا، يمكن لشركة استخدام قواعد مثل الآتية:

• تتجه الطلبات التي تقل عن 500 دولار إلى مدير القسم.
• تتجه الطلبات من 500 إلى 5,000 دولار إلى المدير ومالك مركز التكلفة.
• تتجه طلبات البرامج والخدمات السحابية أيضًا إلى تقنية المعلومات أو الأمن.
• تتجه الطلبات التي تتجاوز 5,000 دولار إلى المشتريات بعد اعتماد الميزانية.
• تتجه المشتريات الرأسمالية إلى مسؤول المالية بغض النظر عن المبلغ.

لا يلزم أن تتطابق القواعد في كل قسم. فقد تحتاج المبيعات إلى موافقة على أدوات موجهة للعملاء، بينما قد تحتاج العمليات إلى فحص إضافي للمعدات. استخدم المنطق الأساسي نفسه في الشركة حتى لا يضطر الموظفون إلى تعلم العملية من جديد كل مرة.

خطط للغياب وحافظ على اكتمال السجل

يحتاج كل موافق إلى بديل. إذا كان المدير في إجازة، فيجب أن يرسل النظام الطلبات الجديدة إلى بديل محدد أو يتيح للمسؤول إعادة تعيين العمل المعلق. ولا ينبغي أن يضطر مقدمو الطلبات إلى ملاحقة أحد عبر البريد الإلكتروني أو المحادثة.

حدد هدفًا زمنيًا للرد. على سبيل المثال، أرسل تنبيهًا إلى الموافق بعد يومي عمل، ثم أرسل الطلب إلى البديل بعد خمسة أيام. يجب أن يدفع التصعيد الطلب إلى الأمام مع الحفاظ على المسار الأصلي وسجل القرارات.

احتفظ بكل قرار في سجل الطلب. اعرض من وافق أو رفض، ومتى تصرف، وتعليقاته. يمنح رفض مثل «استخدم ترخيص الفريق الحالي حتى موعد التجديد» مقدم الطلب خطوة عملية تالية، كما يمنح المشتريات سياقًا للطلب.

يتيح AppMaster للفرق نمذجة حقول الطلبات وبناء منطق الموافقة في عملية أعمال مرئية وعرض الحالة الحالية لمقدمي الطلبات. وتظل الملكية واضحة بدل أن تختفي في سلاسل البريد الإلكتروني.

أنشئ مسار الطلب خطوة بخطوة

يحافظ مسار الطلب الواضح على المشتريات البسيطة من الضياع في البريد الإلكتروني. يجب أن تصف كل حالة الوضع الحالي، وأن يعرف كل شخص متى يحين دوره.

ابدأ بمجموعة صغيرة من الحالات: مسودة، ومُرسل، ومعتمد، ومرفوض، ومطلوب، ومستلم. تجنب التسميات المتشابهة جدًا، مثل «قيد المراجعة» و«بانتظار الموافقة». سيستخدمها الناس بطريقة غير متسقة، وستتأثر التقارير.

يبدأ الطلب كمسودة. يستطيع مقدم الطلب حفظه أو تغيير العنصر أو الكمية أو حذفه. ولا ينبغي للنظام إرسال إشعارات أو حجز الميزانية في هذه المرحلة.

عندما يرسل مقدم الطلب النموذج، تتغير الحالة إلى «مُرسل». اقفل السعر وتفاصيل المورد والمبلغ المطلوب، ما لم يُعد شخص ما الطلب للتعديل. ويمكن للموافق اعتماده أو رفضه أو إعادته مع تعليق قصير.

بعد الموافقة، سلّم الطلب إلى المشتريات. يجب ألا يضع الموظفون الحالة «مطلوب» إلا بعد إنشاء طلب الشراء أو إرساله. فالإذن بالإنفاق لا يثبت أن أحدًا اشترى العنصر.

عند وصول السلع أو بدء الوصول إلى الخدمة أو تأكيد الاشتراك، يضع الشخص المسؤول عن الاستلام الحالة «مستلم». وهذا يمنح المالية ومقدمي الطلبات سجلًا موثوقًا لما وصل.

امنح كل دور إجراءات واضحة

يعمل نظام طلبات الشراء الداخلية البسيط بأفضل شكل عندما تكون لتغييرات الحالة جهات مالكة. لا تسمح لكل مستخدم بتعديل كل طلب مُرسل.

• ينشئ مقدمو الطلبات المسودات ويرسلون الطلبات ويصححون الطلبات المعادة.
• يوافق المديرون ومالكو الميزانية على الطلبات أو يرفضونها أو يعيدونها مع ذكر السبب.
• يسجل موظفو المشتريات معلومات المورد وتفاصيل طلب الشراء وحالة الطلب.
• يؤكد مسؤولو الاستلام التسليم ويضعون الطلبات في حالة «مستلم».
• يطّلع موظفو المالية على السجل الكامل ويصححون حقولًا محدودة، مثل المرجع المحاسبي.

يجب أن يتعامل المسؤول مع الاستثناءات، مثل مغادرة أحد الموافقين للشركة أو وجود طلب مكرر. احتفظ بسجل تدقيق لكل تغيير في الحالة، يتضمن من أجراه ومتى وأي تعليق مرتبط به.

أخبر الأشخاص عندما يحين دورهم

أرسل إشعارًا عندما يصل الطلب المُرسل إلى أحد الموافقين. أدرج عنوان الطلب والمبلغ والقسم والقرار المطلوب. تؤخر رسالة غامضة مثل «لديك مهمة جديدة» الإجراء، لأن الشخص سيضطر إلى البحث عن السياق.

أخطر مقدم الطلب عندما يوافق شخص على الطلب أو يرفضه أو يعيده. واجعل التعليق إلزاميًا عند الرفض أو الإعادة. تمنح عبارة «الميزانية غير متاحة هذا الربع» توجيهًا لمقدم الطلب، أما «لا» فلا تفعل.

يجب أن تتلقى المشتريات إشعارًا بعد الموافقة النهائية. كما يجب أن يتلقى مقدم الطلب تحديثات عندما تضع المشتريات الحالة «مطلوب» و«مستلم». وإذا لم يتصرف أحد خلال مدة محددة، فذكّر المالك الحالي وأرسل نسخة إلى الموافق البديل.

باستخدام AppMaster، يستطيع تطبيق المشتريات من دون برمجة نمذجة الحالات في Data Designer وفرض التغييرات المسموح بها في Business Process Editor. ويبقى كل تسليم مسجلًا في الطلب بدل اعتماده على تذكر شخص ما له.

مثال: طلب اشتراك برنامج

تحتاج مايا، وهي مديرة تسويق، إلى 15 اشتراكًا في أداة لتخطيط وسائل التواصل الاجتماعي. تفتح نظام طلبات الشراء الداخلية وتختار الأداة من كتالوج البرامج بدل إنشاء طلب حر.

يتضمن عنصر الكتالوج المورد ونوع الخطة والسعر لكل مستخدم ودورة الفوترة والفريق المسؤول عن العقد. تدخل مايا 15 ترخيصًا، وتختار مركز تكلفة التسويق، وتضيف سببًا: يحتاج الفريق إلى جدولة المنشورات المشتركة والموافقة عليها.

يحسب التطبيق التكلفة السنوية قبل الإرسال. لدى التسويق ميزانية برامج كافية، لذلك ينجح الطلب في فحص الميزانية. ولو كانت الميزانية غير كافية، لكان بإمكان التطبيق إيقاف الطلب وطلب اختيار مركز تكلفة آخر أو طلب تمويل إضافي. يمنع ذلك المدير من اعتماد شراء لا تستطيع المالية دفعه.

يتلقى رئيس قسم مايا الطلب لأنه يقع ضمن حد إنفاق المدير. وتعرض شاشة الموافقة التكلفة وعدد المستخدمين وسبب الشراء ورصيد الميزانية. فيوافق المدير.

تتلقى المشتريات سجلًا كاملًا يتضمن المورد والخطة والإجمالي السنوي وتاريخ التجديد ومركز التكلفة ونتيجة الميزانية وسبب مايا وموافقة المدير المؤرخة. يتحقق منسق المشتريات مما إذا كانت الشركة تملك اتفاقية مع المورد. إذا كانت موجودة، ينشئ المنسق طلب الشراء من التفاصيل المحفوظة. وإذا لم تكن موجودة، يبدأ مراجعة المورد قبل إرسال الطلب.

يسجل المنسق رقم طلب الشراء ويضع الحالة «مطلوب». وتستطيع مايا رؤية التحديث من دون سؤال المشتريات. وعندما يؤكد المورد التراخيص الخمسة عشر، يضع المنسق الحالة «مستلم» ويسجل من سيدير الحساب.

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

أخطاء تبطئ المشتريات

قد تبدو عملية الشراء بسيطة في مخطط انسيابي، لكنها تظل محبطة للمستخدمين. تظهر المشكلات عادةً عندما يتعامل النظام مع كل طلب على أنه استثنائي أو يفقد السيطرة على التغييرات بعد الموافقة.

إرسال كل طلب إلى مستوى أعلى

ترسل فرق كثيرة كل طلب إلى مدير كبير واحد. فيتحول ذلك الشخص إلى قائمة انتظار للعناصر الروتينية، مثل لوحة مفاتيح بديلة أو تجديد برنامج شهري أو لوازم تقل عن حد إنفاق صغير. وإذا غاب المدير يومين، ينتظر الجميع.

طابق مسارات الموافقة مع تكلفة الطلب وقسمه ونوعه. يستطيع قائد الفريق اعتماد عنصر قياسي من الكتالوج تحت حد معين. ويراجع مالك القسم المشتريات الأكبر. وتنضم المالية عندما يؤثر الطلب في الميزانية أو يتجاوز حدًا. يجب أن تصل الاستثناءات إلى كبار القادة، لا الطلبات العادية.

السماح بتغيير الطلبات المعتمدة من دون تنبيه

تنطبق الموافقة النهائية على عنصر وكمية ومورد وسعر محددين. وإذا غيّر شخص هذه التفاصيل لاحقًا، فقد لا تعود الموافقة مطابقة للإنفاق.

ضع قواعد للتعديلات المهمة. يجب أن يعيد تغيير 10 تراخيص إلى 12، أو تغيير السعر من 500 إلى 1,200 دولار، الطلب إلى المراجع المناسب. ويمكن أن تبقى الملاحظات البسيطة، مثل جهة اتصال التسليم، قابلة للتعديل من دون إعادة بدء سير عمل الموافقة.

يستطيع تطبيق مشتريات من دون برمجة الاحتفاظ بسجل للتعديلات وإعادة فتح الموافقة عند تغيير الحقول الخاضعة للرقابة. وهذا يمنع المفاجآت عندما تقارن المالية المبلغ المعتمد بالفاتورة.

إغلاق الطلب مبكرًا

الموافقة ليست نهاية الشراء. فما زال على فريق المشتريات تسجيل المورد ورقم طلب الشراء والسعر النهائي وتاريخ الطلب وحالة التسليم. وإذا أغلق شخص الطلب قبل وجود هذه التفاصيل، فسيتعين على الموظفين البحث لاحقًا في الرسائل وجداول البيانات.

استخدم حالات واضحة مثل «معتمد» و«مطلوب» و«مستلم» و«مغلق». لا تنقل الطلب إلى «مغلق» إلا بعد أن يسجل المشتري تفاصيل الطلب ويؤكد التسليم. ويجب أن يظل الاشتراك السنوي المعتمد في حالة «معتمد» حتى يسجل المشتري طلب المورد أو مرجع التجديد.

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

فحوصات سريعة قبل الإطلاق

يكشف الاختبار القصير معظم المشكلات قبل أن يعتمد الموظفون على نظام طلبات الشراء الداخلية. اطلب من مجموعة صغيرة إرسال طلبات واقعية، مثل اللوازم المكتبية وتجديد برنامج وعقد خدمة. وأشرك مقدمي الطلبات والموافقين والموظفين الذين ينشئون طلبات الشراء.

يحتاج كل طلب إلى مالك واضح وحالة ظاهرة. ويجب أن يتغير المالك عندما تنتقل المسؤولية من مقدم الطلب إلى مدير أو مشترٍ. كما ينبغي أن توضح تسميات الحالة ما حدث، مثل مسودة أو مُرسل أو معتمد أو مرفوض أو مُسلّم إلى المشتريات.

قبل فتح التطبيق للجميع، تأكد من أن كل طلب يعرض مالكه وحالته الحالية ومبلغه والموافق التالي. قارن قواعد الموافقة بحدود الإنفاق الفعلية وقواعد الأقسام. وتحقق من أن المشتريات تستطيع رؤية المورد والسعر المعروض والكمية المعتمدة وتاريخ التسليم المطلوب.

اختبر طلبًا يتجاوز الميزانية وتأكد من أن التطبيق يوقفه أو يرسله إلى الشخص المناسب. وارفض طلبًا آخر مع ذكر سبب واضح، ثم تأكد من أن مقدم الطلب يتلقى السبب ويستطيع تحديث النموذج.

استخدم أرقامًا حقيقية لاختبار الميزانية. امنح فريقًا ميزانية شهرية متبقية قدرها 2,000 دولار، ثم أرسل طلبًا بقيمة 2,400 دولار. قرر ما إذا كان النظام سيمنعه أو يطلب موافقة المالية أو يسمح لمالك الميزانية بنقل الأموال. يجب أن يرى كل المعنيين النتيجة نفسها.

اختبر أيضًا التغييرات بعد الموافقة. قد يزيد مقدم الطلب عدد الشاشات من 10 إلى 15، أو قد يرفع المورد السعر المعروض. يجب أن يعيد سير عمل الموافقة الطلب إلى الموافقة أو يوضح التغييرات التي لا تحتاج إلى مراجعة أخرى. تؤدي التغييرات الصامتة إلى خلافات لاحقًا.

وأخيرًا، اختبر تسليم طلب الشراء. يجب أن تتلقى المشتريات التفاصيل المعتمدة في مكان واحد بدل إعادة كتابتها من البريد الإلكتروني أو المحادثة. في AppMaster، تستطيع الفرق اختبار هذه المسارات بسجلات تجريبية وتعديل القواعد المرئية قبل نشر التطبيق. احتفظ بسجل مختصر للاختبارات الفاشلة، وأصلح القاعدة المسؤولة عن كل منها، ثم أعد الاختبار.

اختر الخطوات التالية

ابدأ بقسم واحد لديه مشتريات متكررة وسلسلة موافقات يمكن إدارتها. وتعد برامج تقنية المعلومات أو اللوازم المكتبية أو اشتراكات التسويق نقاط بداية عملية. امنح هذه المجموعة كتالوجًا قصيرًا يضم العناصر الشائعة والأسعار التقديرية والمعلومات التي تحتاجها المشتريات.

حافظ على تركيز الإصدار الأول. يجب أن يرسل مقدم الطلب حاجة واضحة، ويرى الموافق التكلفة وحالة الميزانية، وتتلقى المشتريات طلبًا كاملًا بعد الموافقة. أضف أنواع الطلبات غير المعتادة بعد أن يعمل المسار الأساسي بشكل موثوق.

اطلب ملاحظات الأشخاص الذين يستخدمون كل جزء من نظام طلبات الشراء الداخلية بعد الأسابيع الأولى. يستطيع مقدمو الطلبات تحديد الحقول المربكة. ويمكن للموافقين شرح المواضع التي يحتاجون فيها إلى مزيد من السياق. كما يستطيع موظفو المشتريات الإشارة إلى تفاصيل المورد الناقصة أو الطلبات التي ما زالت تصل خارج التطبيق.

استخدم هذه الملاحظات لحذف الحقول التي لا يستخدمها أحد، وإضافة عناصر كتالوج للمشتريات المتكررة، وتوضيح حدود الموافقة، وإظهار الشخص المسؤول التالي، وتسجيل سبب إعادة الطلب أو رفضه.

يمكن أن يساعد AppMaster الفرق على إنشاء تطبيق مشتريات من دون برمجة، من دون البدء بمشروع تقني فارغ. تستطيع الفرق بناء نماذج طلبات الموظفين، واستخدام Business Process Editor لفحوصات الميزانية ومسارات الموافقة، وإنشاء شاشات منفصلة للمديرين وموظفي المشتريات. كما يمكن لـ Data Designer حفظ عناصر الكتالوج والأقسام والموردين والميزانيات والطلبات في مكان واحد.

يكشف المشروع التجريبي الصغير المشكلات العملية بسرعة. إذا استمر الموظفون في إرسال الطلبات عبر البريد الإلكتروني، فاكتشف السبب قبل إضافة مزيد من القواعد. أنشئ مسارًا يختاره الناس لأنه أوضح وأسرع من الحل البديل. وبعد أن يعمل المشروع التجريبي بسلاسة، عدّل الهيكل للقسم التالي مع إبقاء الكتالوج وقواعد الموافقة مرتبطين بطريقة إنفاق ذلك الفريق.