لا توجد مرحلة بناء ينتظرها العميل دون فهم. تتبع كل جلسة عمل نفس الحلقة، في حساب العميل الخاص، على شاشات حقيقية باستخدام بيانات العميل النموذجية: عرض سطر دفتر الأستاذ، وتكوينه مباشرةً وبدون كتابة أي كود، حيث يقوم العميل بإجراء التغيير، والتحقق منه باستخدام البيانات النموذجية، وتسجيله، ثم وضع علامة على السطر.
إذا لم يكن العميل حاضرًا في الجلسة، فلن تُعقد. يجب أن يكون المستخدم الرئيسي حاضرًا بحلول اليوم 14؛ إذا كان برنامج TRANXACT لا يزال يستخدم لوحة المفاتيح بحلول اليوم 13، فيُرجى الإبلاغ عن ذلك في اجتماع المتابعة اليومي باعتباره خطرًا على التبني.
سبعة أيام، هيكلة قبل المعاملات (الوضع الافتراضي المقترح)
| يوم تي | ركز | تم التكوين |
|---|---|---|
| تي-17 | بناء | الكيانات، دليل الحسابات، التقويم المالي، الأبعاد |
| تي-16 | المال والامتثال | العملات والصرف الأجنبي، والرموز الضريبية، وترقيم المستندات، والبنوك |
| تي-15 | الأشخاص وإمكانية الوصول | الأدوار والصلاحيات، ومجموعات تسجيل الدخول الموحد، وتسلسل الموافقة |
| تي-14 | البيانات الرئيسية | العملاء، والموردون، والمنتجات، والموظفون — يقوم برنامج ASK بإنشاء عمليات إنشاء جماعية من المستخلصات |
| تي-13 | التدفقات والقواعد | مسارات الموافقة، والنشر، والمطابقة، وقواعد التسعير |
| تي-12 | تفاصيل الوحدة | مسار إدارة علاقات العملاء، وتكاليف سلسلة التوريد، وعناصر رواتب الموارد البشرية، ومفاتيح الوحدات النمطية |
| تي-11 | التكاملات وقوائم الانتظار | عملاء واجهة برمجة التطبيقات، ونقاط نهاية البنوك/الضرائب/الرواتب، وقوائم الانتظار لكل دور |
حافظ على الترتيب حتى عندما يختلف ترتيب دفتر الأستاذ الملائم: فالهيكل أولاً يعني أن عملية ترحيل الخرائط يمكن أن تبدأ في T-15، وأن خريطة دفتر الأستاذ العام التي يعتمد عليها كل شيء آخر موجودة قبل البيانات الرئيسية.
يقوم ASK بالعمل الشاق
إنشاء 2400 عميل دفعة واحدة من بيانات مستخرجة مع تحديد شروط الدفع حسب القطاع؛ صياغة قاعدة ترحيل لتوزيع الشحن حسب مركز تكلفة المستودع المستلم؛ إنشاء موظف حسابات دائنة يمكنه إدخال الفواتير التي تزيد قيمتها عن 10000 دون الموافقة عليها؛ سرد جميع مسارات الموافقة دون الحاجة إلى مُعتمد احتياطي. يقوم نظام ASK بذلك بنفس الصلاحيات وسجل التدقيق الخاص بالنقر البشري، ويراجع المستخدم الرئيسي كل نتيجة قبل وضع علامة صح على السطر.
طلبات تبدو وكأنها شفرة برمجية
| "نحن بحاجة إلى..." | التكوين الذي يجيب على ذلك |
|---|---|
| عملية الموافقة الفريدة لدينا | مسار موافقة متعدد الخطوات مع قواعد المبلغ والكيان والبعد |
| تصميم فاتورة مخصص | نموذج مستند يحتوي على حقول وشعار ولغة لكل كيان |
| حقل غير موجود | حقل مخصص بدون كتابة أي كود، قابل للاستخدام في التقارير والقواعد |
| تقريرنا القديم كما هو تمامًا | أداة إنشاء التقارير أو لوحة المعلومات - تحدَّى التصميم؛ غالبًا "غير ضروري". |
| واجهة للبنك أو نظام إدارة التصنيع | عميل واجهة برمجة تطبيقات (API) ذو دور محدد النطاق؛ تبادل الملفات عند الحاجة |
| تنبيهات عند حدوث X | قاعدة قائمة انتظار الإجراءات الواعية بالأدوار |
التكاملات على مدار الساعة (الوضع الافتراضي المقترح)
القائمة والمالكين بحلول T-18؛ عملاء واجهة برمجة التطبيقات ونقاط نهاية اختبار الشركاء بحلول T-13؛ اختبارات التكامل بحلول T-10 (الرواتب T-9، ذكاء الأعمال T-6؛ تسجيل الدخول الموحد بحلول T-17، لأن البروفة تتطلب ذلك)؛ من البداية إلى النهاية في التشغيل التجريبي في T-3؛ التبديل إلى الإنتاج في T-0.
في حال عدم تمكّن الشريك من توفير نقطة نهاية اختبارية بحلول T-13، يتم نقل عملية التكامل إلى T-Plus عبر خطوة وسيطة يدوية، تتضمن تحميل ملف بنكي يدوي، وتحميل الملف عبر البوابة الإلكترونية من قِبل قسم المالية، وتشغيل نظام الرواتب القديم مع استيراد دفتر اليومية. أما نظام تسجيل الدخول الموحد (SSO) فلا يتطلب خطوة وسيطة، فهو ضروري لإجراء البروفة.
يقدم بنك كالدروود نقطة الاختبار الخاصة به في الوقت المحدد؛ ولا تزال بيئة الاختبار الخاصة ببوابة الضرائب الخاصة به غير متاحة في T-13. يصبح التكامل الضريبي خط T-Plus، وتقوم الإدارة المالية بتحميل الفواتير الإلكترونية إلى البوابة يدويًا خلال الأسابيع الأولى - يتم التدرب عليها في T-1 مثل كل شيء آخر.
جرب في T-12، يطلب أحد المستخدمين الرئيسيين من شاشة فاتورة المورد عرض حقل كان موجودًا في النظام القديم. هل هذا رمز برمجي؟
لا، إنه حقل مخصص لا يتطلب كتابة أي كود في النموذج، ويمكن استخدامه في التقارير والقواعد. يُضاف إليه سطر في دفتر الأستاذ، ويتم تكوينه في الجلسة التي يديرها المستخدم الرئيسي، ويتم التحقق منه باستخدام بيانات نموذجية، وتسجيله في دفتر عمل التكوين، وإجراء فحص تكوين له في خطة الاختبار.