الموضوع 5.4 — تخطيط موارد المؤسسة (ERP)

بإيجاز: تخطيط موارد المؤسسة هو نظام المكتب الخلفي المُدمَج — المالية، الموارد البشرية، الرواتب، الشراء، وسلسلة التوريد — الذي يعمل كنظام سجل المؤسسة للمال، الناس، والمخزون، ويدعم بهدوء تقريبًا كل طريقة عمل في هذا الكتاب.

لماذا يهم هذا في الصحة والرعاية#

يحصل التحول الرقمي في الصحة والرعاية على اهتمامه من الأنظمة السريرية — السجل المريض الإلكتروني، سجل الرعاية المشترك، تطبيق المريض. لكن لا شيء من ذلك يعمل بلا المكتب الخلفي غير اللامع تحته. يجب تعيين، جدولة، ودفع رواتب الموظفين؛ يجب التعاقد مع الموردين وتسويتهم؛ يجب طلب وتتبع الأدوية، الأجهزة، والمُستهلَكات؛ ويجب حساب كل جنيه مقابل ميزانيات عامة مُقيَّدة بشدة. ERP هو حيث يحدث ذلك، وعندما يفشل، العواقب فورية: موظفون غير مدفوعين، شراء مُتوقِّف، حسابات غير مُصالَحة، ووظيفة مالية تطير بلا رؤية.

النطاق ضخم. تُشغِّل خدمات الأعمال المشتركة لـNHS (NHS SBS)، مشروع مشترك أُنشئ عام 2004، منصة مالية وشراء وطنية مُستنِدة إلى Oracle تُعالِج ملايين الفواتير وتُتعامَل مع حصة كبيرة جدًا من إجمالي صرف NHS لأكثر من مئة مؤسسة NHS (انظر المصادر الرئيسية). قرارات ERP ليست بالتالي اهتمامًا ماليًا مُتخصِّصًا — تُشكِّل إدارة القوى العاملة، تحكم المال العام، وجودة البيانات التي يعتمد عليها كل تحليل لاحق. لمدير، ERP هو كل من مُمكِّن أساسي وأحد البرامج الأعلى خطرًا التي ستُحاول مؤسسة الشروع فيها أبدًا.

مفاهيم جوهرية#

ما هو ERP. جناح تخطيط موارد مؤسسة وحدات مُتكامِل واحد يُشارِك قاعدة بيانات واحدة ومجموعة واحدة من البيانات الرئيسية، يُغطّي عمليات إدارية جوهرية للمؤسسة: الدفتر العام والمحاسبة المالية، الحسابات الدائنة والمدينة، إدارة الموارد البشرية والقوى العاملة، الرواتب، الشراء (الشراء-إلى-الدفع)، المخزون وسلسلة التوريد، وبشكل متزايد التخطيط والتحليلات (FP&A — التخطيط والتحليل المالي). نقطة "التكامل" هي أن طلب شراء، إيصال استلام سلع، وفاتورة تُصالَح تلقائيًا لأنها نفس البيانات، لا ثلاث نسخ.

نظام السجل. ERP هو المصدر الموثوق للبيانات المالية والموارد — الدفتر الذي يثق به المُدقِّقون والرواتب التي يُدفَع منها للموظفين. قد تحمل أنظمة أخرى نسخًا تشغيلية، لكن ERP هو نسخة الحقيقة للمال، وغالبًا، لسجل الموارد البشرية الجوهري.

البيانات الرئيسية. بيانات المرجع المشتركة التي يعتمد عليها كل شيء آخر: دليل الحسابات، مراكز الكلفة، سجلات الموردين، كتالوج العناصر، وسجلات الموظفين. البيانات الرئيسية هي المُحدِّد الهادئ لنجاح ERP — بيانات رئيسية قذرة، مُكرَّرة، أو غير مُتَّسِقة تُفسِد التقارير، تكسر التصالح، وتُقوِّض كل عملية مبنية فوقها.

منصات شائعة في الصحة والقطاع العام. في NHS والقطاع العام الأوسع بالمملكة المتحدة منصات ERP الأساسية هي Oracle (المُهيمِنة، إلى حد كبير من خلال NHS SBS واتحادات مثل NEP)، SAP، Unit4 (مُختارة على نطاق واسع من مؤسسات ائتمانية، جامعات، وسلطات محلية)، وMicrosoft Dynamics 365. تُشغِّل السلطات المحلية التي تُقدِّم رعاية اجتماعية للبالغين نفس فئة الأنظمة لماليتها وشرائها. الاتجاه الحديث للسير هو ERP سحابي (برمجية-كخدمة) بدلًا من تثبيتات داخلية.

خدمات مشتركة. بدلًا من تشغيل كل مؤسسة ERP خاصًا بها، تُشارِك مؤسسات كثيرة منصة مشتركة وعملية مكتب خلفي مشتركة — نموذج NHS SBS، واتحادات NHS تُشغِّل نُسخ Oracle Cloud مُقالَبة. تُبادِل الخدمات المشتركة بعض المرونة المحلية بالتوحيد، اقتصادات الحجم، وعبء تنفيذ ودعم جماعي أصغر.

أفضل الممارسات#

  1. عامل البيانات الرئيسية كالأساس، لا فكرة لاحقة. طهِّر ونزِّل الازدواج من دليل الحسابات، سجلات الموردين، كتالوج العناصر، وبيانات الموظفين قبل الترحيل، وضع ملكية حوكمة بيانات مستمرة في موضعها. أكثر فشل ERP ضررًا يُتتبَّع لبيانات رئيسية سيئة لا تستطيع أي كمية من البرمجيات الجيدة إصلاحها؛ مسار عمل جودة البيانات ليس اختياريًا.

  2. تبنَّ المعيار؛ قلِّل التخصيص. هيِّئ ERP لقالب المورد أو الاتحاد المعياري حيث تكون العملية سلعة فعليًا، واحفظ التغيير المُخصَّص للمُميِّز الحقيقي النادر. التخصيص الثقيل يُضخِّم الكلفة، يُدمِّر قابلية الترقية، ويُعيد استيراد الفوضى المحلية التي كنت تحاول الهروب منها — يُعاقِب ERP السحابي بشكل خاص غريزة "جعله يشبه نظامنا القديم".

  3. صمِّم التكاملات بتعمُّد. لا يقف ERP بمفرده: يجب أن يتبادل بيانات مع أنظمة قوى عاملة وجدولة إلكترونية، أنظمة سريرية وصيدلانية (للمخزون والتكليف)، مصرفية، وتحليلات. ارسم كل واجهة، امتلك عقود البيانات، واختبرها من طرف لطرف — رواتب تُغذّى بتغذية جدولة معطلة تدفع للناس بشكل خاطئ، وذلك فشل مُدمِّر للثقة.

  4. شغِّل استبدال ERP كبرنامج كبير، مع إدارة التغيير في قلبه. تنفيذ ERP هو برنامج تغيير أعمال يحدث أن يشمل برمجيات، لا مشروع تقنية معلومات. زوِّده بموارد بانضباط برنامج (انظر الموضوع 5.2 — إدارة البرنامج) وجهد إدارة تغيير حقيقي (انظر الموضوع 8.1 — إدارة التغيير)، لأن معظم ألم ERP هو ناس وعملية، لا تقنية.

  5. كن أمينًا حول خطر برنامج ERP. تحمل تنفيذات ERP الكبيرة سمعة مكسوبة بشدة بتجاوز الوقت والكلفة وتسليم فائدة أقل من المُتوقَّع؛ أدبيات الفشل واسعة وعابرة للقطاعات. ابنِ احتياطًا، تجنَّب انطلاقًا انفجاريًا كبيرًا حيث نهج مُتدرِّج ممكن، ولا تسمح أبدًا لجدول زمني متفائل بتجاوز الجاهزية — تاريخ مُنزلِق قابل للتعافي، تحويل رواتب أو دفتر مُخرَّب ليس كذلك.

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

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

  8. زِن الخدمات المشتركة وERP السحابي على مفاضلاتها الحقيقية. تُقدِّم المنصات المشتركة (NHS SBS، اتحادات بأسلوب NEP) وERP السحابي توحيدًا، حجمًا، ترقيات مستمرة، وعبئًا محليًا أخف، بكلفة بعض المرونة المحلية واعتماد على المزوِّد. اختر بتعمُّد: لمعظم المؤسسات مكسب التوحيد يتجاوز المرونة المفقودة، لكن يجب اتخاذ القرار بعيون مفتوحة، لا افتراضيًا.

أسئلة للمناقشة مع فريقك#

  1. كم نحن واثقون — بالدليل، لا الضمان — حول جودة البيانات الرئيسية التي سنحملها إلى ERP جديد، ومن يملكها بعد الانطلاق؟ البيانات الرئيسية هي المُحدِّد الهادئ لنجاح ERP، ومع ذلك تُعامَل بشكل روتيني كمهمة صيانة ترحيل بدلًا من الأساس الذي هي عليه، لذا يختبر هذا السؤال ما إذا نظر الفريق بشدة لدليل الحسابات، سجلات الموردين، كتالوج العناصر، والملف الرئيسي للموظفين أو يأمل ببساطة أنها نظيفة. في بيئة صحة ورعاية المخاطر ملموسة: سجلات موردين مُكرَّرة تكسر تصالح الشراء-إلى-الدفع، ملف رئيسي للموظفين لا يتفق مع ESR يدفع للناس بشكل خاطئ، ودليل حسابات غير مُتَّسِق يُفسِد كل تقرير مالي لاحق يعتمد عليه المجلس والمُدقِّقون. التوتر الذي يستحق النقاش هو الجذب للترحيل بالجملة لضرب موعد مقابل شهور من التطهير والتنزيل غير اللامعين اللذين تتطلبهما الممارسة الجيدة، وما إذا كان أي شخص أعلى مستعدًا لتمويل مسار عمل جودة بيانات لا يُظهِر منتجًا مرئيًا. إجابة قوية تستشهد بأعداد فعلية — كم موردًا مُكرَّرًا، كم سجل موظف غير مُصالَح — بدلًا من إحساس عام أن "البيانات جيدة إلى حد كبير". يجب أن تُسمّي أيضًا الشخص وآلية الحوكمة المساءلين عن جودة البيانات الرئيسية بعد الانطلاق، لأن بيانات تُطهَّر مرة ثم تُترَك بلا حوكمة تنجرف ببساطة للفوضى.

  2. أين نحن مُغرَون فعليًا بتخصيص ERP لحفظ عملية مألوفة، وهل ذلك الاختلاف مُميِّز حقيقي أو فقط الفوضى القديمة التي نحاول الهروب منها؟ التخصيص الثقيل هو فخ ERP المؤسسي الكلاسيكي: يُضخِّم الكلفة، يُدمِّر قابلية الترقية، ويُعيد استيراد التشتت المحلي نفسه الذي كان يُقصَد بالبرنامج إزالته، ويُعاقِب ERP السحابي بشكل خاص غريزة "جعله يشبه نظامنا القديم". يسأل هذا السؤال الفريق أن يكون مُحدَّدًا حول أي عمليات سيُصِر على ثني البرنامج لتُناسِبها، وتبرير كل واحدة مقابل اختبار صارم لما إذا كانت مُميِّزًا حقيقيًا أو فقط عادة مُريحة. يهم النقاش لأنه في الصحة والرعاية معظم عملية المكتب الخلفي — الدفتر العام، موافقات الشراء، إدارة الرواتب — سلعة فعليًا، لذا يجب أن يكون الافتراضي الأمين تبني قالب المورد أو الاتحاد المعياري وتغيير العملية، لا البرنامج. تشمل الزوايا الملموسة سرد كل تخصيص مطلوب والسؤال من يستفيد، أي كلفة ترقية يُقفِلها، وما إذا كانت مؤسسة ائتمانية مجاورة على نفس القالب تُدار بدونه. إجابة جيدة تُميِّز الاستثناء المشروع النادر من الطلبات الكثيرة المدفوعة بالنفور من التغيير، وتُدرِك أن تبني المعيار مشكلة إدارة تغيير وقيادة، لا تقنية. يجب أن تُواجِه أيضًا الكلفة الطويلة المدى: كل تغيير مُخصَّص ضريبة تُدفَع في كل إصدار سحابي مستقبلي.

  3. هل زوَّدنا بأمانة موارد الجانب البشري والعملياتي لهذا تغيير ERP — تحويل، تشغيل متوازي، عناية مُكثَّفة، تدريب، واختبار تكامل — أم نُشغِّله بهدوء كمشروع تقنية معلومات؟ أدبيات الفشل واضحة بلا لبس أن معظم ألم ERP ناس وعملية بدلًا من تقنية، لذا يُكشِف هذا السؤال ما إذا كان البرنامج جهد تغيير أعمال فعليًا أو تبديل تقنية معلومات يرتدي ثياب برنامج. الفترة حول الانطلاق هي عندما يبقى الموردون بلا دفع، تنكسر نهاية الشهر، ويُدفَع للموظفين متأخرًا، وكل واحدة من هذه في هيئة صحة عامة ليست بداية خشنة بل فشل مُدمِّر للثقة وربما مثير للأخبار. التوتر للنقاش هو الضغط الثابت لتقصير التشغيل المتوازي، تنحيل فريق العناية المُكثَّفة، وضغط الجدول الزمني لضرب موعد مفروض، مقابل الواقع أن تاريخًا مُنزلِقًا قابل للتعافي بينما تحويل رواتب أو دفتر مُخرَّب ليس كذلك. تشمل الزوايا المفيدة المرور بكل تكامل — جدولة إلكترونية، ESR، مخزون صيدلاني، مصرفي، تحليلات — والسؤال أيها اختُبِر من طرف لطرف مقابل مُفترَض، وما إذا كان أصحاب العملية في المالية، الشراء، والموارد البشرية قد أُلحِقوا فعليًا لإعادة تصميم تدفقات عملهم. إجابة أمينة تُظهِر موارد إدارة تغيير، تدريب، وتصالح مُسمّاة في الخطة بدلًا من سطر يقول "تقنية المعلومات ستتولى ذلك"، ومستعدة لتدريج الانطلاق حيث يُضيف تحويل انفجاري خطرًا يمكن تجنبه. يجب أن تعترف أيضًا أن الجاهزية، لا التقويم، يجب أن تحكم قرار المواصلة.

  4. بشأن سؤال الخدمات المشتركة وERP السحابي، هل وزنَّا التوحيد الذي سنكسبه مقابل المرونة المحلية التي سنُسلِّمها — واتخذنا ذلك القرار بتعمُّد بدلًا من افتراضيًا؟ تُقدِّم المنصات المشتركة مثل NHS SBS ونُسخ Oracle Cloud الاتحادية، وERP السحابي بشكل أوسع، جوائز حقيقية — اقتصادات الحجم، ترقيات مستمرة، عبء تنفيذ ودعم محلي أخف — لكنها تشتري ذلك بخسارة حقيقية للتحكم المحلي واعتماد صارم على خارطة طريق ووتيرة إصدار المزوِّد. يفرض هذا السؤال على الفريق تسمية أي مرونة تهمهم فعليًا واختبار ما إذا كانت تستحق كلفة تشغيل، تصحيح، ودعم مكتبهم الخلفي بشكل منفصل. التوتر في بيئة صحة ورعاية يُشدَّد بحقيقة أن معظم عملية المكتب الخلفي سلعة، لذا مكسب التوحيد يتجاوز عادةً المرونة المفقودة — لكن "عادةً" ليست "دائمًا"، والانجراف لمنصة مشتركة بلا فحص المفاضلة هو كيف تنتهي المؤسسات باستياء من قالب لم تختره أبدًا بوعي. تشمل الزوايا الملموسة السؤال عن أي عمليات محلية سيُحارِب الفريق للاحتفاظ بها ولماذا، ماذا يحدث عندما يُغيِّر الاتحاد القالب تحتهم، وما إذا كانت شروط الخروج وقابلية نقل البيانات مفهومة قبل التوقيع. إجابة قوية تعامل هذا كخيار استراتيجي مُتَّخَذ بعيون مفتوحة، تزن اعتماد المزوِّد وخطر خارطة الطريق مقابل الحجم وراحة الترقية، بدلًا من الافتراضي للخيار المشترك لأنه رائج أو التمسك بمنصة مُخصَّصة من العادة.

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

  6. هل نحن أمينون فعليًا حول خطر برنامج ERP — سجل القطاع من التجاوز وسوء التسليم — وهل بنينا جدولنا الزمني، احتياطنا، ونهج انطلاقنا حول ذلك الواقع بدلًا من خطة متفائلة؟ تحمل تنفيذات ERP الكبيرة سمعة مكسوبة بشدة وعابرة للقطاعات بتجاوز الوقت والكلفة وتسليم فائدة أقل من المُتوقَّع، ويسأل هذا السؤال ما إذا استوعب الفريق تلك أدبيات الفشل أو يفترض بهدوء أنه سيكون الاستثناء. المخاطر في هيئة صحة عامة لا تُسامِح: تاريخ مُنزلِق قابل للتعافي، لكن تحويل رواتب أو دفتر مُخرَّب حدث مُدمِّر للثقة ومثير للأخبار بعواقب برلمانية وصحفية، لذا التفاؤل الذي يتجاوز الجاهزية ليس شجاعة بل تهورًا. التوتر للنقاش هو الضغط الثابت — من مواعيد مفروضة، كلفة غارقة، ورغبة إظهار تقدم — لضغط الجدول الزمني، تنحيل الاحتياط، وتفضيل انطلاق انفجاري كبير على مُتدرِّج سيكون أكثر أمانًا لكن أبطأ. تشمل الزوايا الملموسة السؤال ماذا تفترض الخطة أنه سيسير بشكل صحيح، أين يجلس الاحتياط فعليًا، ما إذا كان تحويل مُتدرِّج ممكنًا، وما المعايير الصريحة لتأخير الانطلاق إن لم تكن الجاهزية موجودة. إجابة جيدة تُسمّي المخاطر المُحدَّدة التي يحملها هذا البرنامج بدلًا من الإشارة لخطر ERP عمومًا، تبني احتياطًا حقيقيًا وقرار تدريج قابل للدفاع، وتعامل "ليس الآن" مُستنِدًا للبيانات كنتيجة مشروعة ومُتوقَّعة بدلًا من فشل شجاعة.

في الممارسة: مثال من الصحة والرعاية#

تُشغِّل مؤسسة ائتمانية NHS حادة نظام مالية وشراء داخلي عمره خمسة عشر عامًا سيتوقف مورده قريبًا عن دعمه. التقارير تستغرق أيامًا، الشراء-إلى-الدفع يدوي بشدة، وتأسيس القوى العاملة يعيش في تشابك من جداول البيانات لا يتفق تمامًا أبدًا مع الرواتب. تُقرِّر المؤسسة الانتقال لERP سحابي مُقدَّم من خلال نسخة Oracle Cloud المُقالَبة لاتحاد NHS إقليمي، جنبًا إلى جنب مع مقدمين مجاورين.

يقاوم مدير المالية إغراء معاملة هذا كتبديل تقنية معلومات. يُقام برنامج برعاية تنفيذي، مدير برنامج بدوام كامل، و— بشكل حاسم — مسار عمل جودة بيانات يصرف شهورًا لتطهير دليل الحسابات، تنزيل ازدواج اثني عشر ألف سجل مورد، وتصالح الملف الرئيسي للموظفين مقابل ESR (سجل الموظفين الإلكتروني لNHS) قبل أي ترحيل. يُلحَق أصحاب العملية في المالية، الشراء، والموارد البشرية بـإعادة تصميم تدفقات عملهم لقالب الاتحاد بدلًا من تكرار النظام القديم.

تختار المؤسسة انطلاقًا مُتدرِّجًا: المالية والشراء أولًا، القوى العاملة والتقارير في موجة لاحقة، بتشغيل متوازٍ عبر نهايتي شهر وفريق عناية مُكثَّفة مُزوَّد جيدًا بالموظفين في وضع الاستعداد. تُرسَم وتُختبَر التكاملات للجدولة الإلكترونية، البنك، ومستودع التحليلات من طرف لطرف. الانطلاق ليس بلا ألم — يتراكم تراكم دفع للموردين في الأسبوع الأول ويستغرق أسبوعين لتصفيته — لكن لأن التصالح والعناية المُكثَّفة زُوِّدا بالموارد بشكل صحيح، لا يُدفَع لأي موظف متأخرًا وتُغلَق نهاية الشهر في الوقت.

بعد عام، تُغلِق المؤسسة كتبها في أيام بدلًا من أسابيع، موافقات الشراء مُفروضة داخل النظام، وأخيرًا يتصالح التأسيس مع الرواتب. تعني منصة الاتحاد المشتركة أيضًا أن الترقية التالية تصل كإصدار سحابي روتيني بدلًا من مشروع آخر متعدد السنوات.

عدسات قطاعية#

شركة ناشئة#

نادرًا ما تُشغِّل شركة ناشئة في الصحة الرقمية ERP كاملًا؛ تُخيِّط معًا أدوات SaaS سحابية — حزمة محاسبة خفيفة، تطبيق موارد بشرية-ورواتب، بضعة جداول بيانات — لأن جناحًا مُدمَجًا ثقيلًا غير متناسب مع فريق من ثلاثين. لا يزال انضباط نظام السجل يهم، ومع ذلك: حتى في مرحلة البذرة، دليل حسابات نظيف واحد ومصدر رواتب موثوق واحد يمنعان فوضى التصالح التي تُخيف المستثمرين خلال العناية الواجبة. الحركة الصحيحة هي حفظ المجموعة بسيطة، قابلة للتكامل، ومُحكَمة جيدًا، وتأجيل ERP "حقيقي" حتى يتطلبه الحجم فعليًا. خطر الشركة الناشئة صورة معكوسة لخطر المؤسسة الكبيرة — ليس تخصيصًا مفرطًا، بل انتشارًا: دستة من تطبيقات غير مُتصِلة بلا مالك بيانات رئيسية ولا أحد مساءل عن الأرقام.

شركة صغيرة#

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

مؤسسة كبيرة#

تُشغِّل مؤسسة ائتمانية كبيرة أو شركة تقنية صحية ERP كاملًا مُدمَجًا كنظام سجل حرج للمهمة، واستبداله واحد من أعلى البرامج خطرًا التي ستُحاول الشروع فيها أبدًا. الإغراء المؤسسي هو تخصيص ثقيل لحفظ عمليات قديمة مألوفة؛ الانضباط هو تبني القالب المعياري، تزويد مسار عمل جودة بيانات جدي بالموارد، وتشغيل الانطلاق بتشغيل متوازٍ وفترة عناية مُكثَّفة مُزوَّدة جيدًا بالموظفين. تتضاعف التكاملات — الجدولة الإلكترونية، ESR، مخزون الصيدلة، المصرفي، التحليلات — وكل واحدة فشل مُدمِّر للثقة إن كسرت بصمت الرواتب أو تصالح نهاية الشهر. لأن معظم الألم ناس وعملية بدلًا من تقنية، إدارة التغيير (انظر الموضوع 8.1 — إدارة التغيير) هي حيث يُكسَب أو يُخسَر برنامج المؤسسة الكبيرة. المساءلة لمجلس ومُدقِّقين تجعل تحويل دفتر أو رواتب مُخرَّب حادثة حوكمة، لا فقط انتكاسة تقنية معلومات.

حكومة#

على نطاق وطني وخدمة مشتركة، ERP أداة توحيد: توجد NHS Shared Business Services ونُسخ Oracle Cloud الاتحادية لإعطاء مؤسسات كثيرة منصة مُقالَبة واحدة، تُبادِل مرونة محلية باقتصادات الحجم وترقيات مستمرة. تُضيف المساءلة الحكومية فحصًا للشراء العام (أطر تنافسية، ضمان قيمة مقابل المال) لكل قرار ERP كبير، وفشل تحويل وطني له عواقب برلمانية وصحفية. القدرة الحقيقية للمركز هي التجميع — تفويض أو تحفيز منصات مشتركة بحيث لا تُشغِّل، تُصحِّح، وتفشل بشكل منفصل عشرات المؤسسات الائتمانية والسلطات المحلية مكتبها الخلفي الخاص. التوتر المُحدِّد هو بين التوحيد الوطني والاستقلالية المحلية: اضغط القالب بشدة جدًا ويتوقف التبني في استياء؛ برفق جدًا ويستمر التشتت الذي يوجد ERP لإزالته بهدوء.

أنماط فشل شائعة#

  • بيانات رئيسية قذرة مُرحَّلة بالجملة. تُحمَل التكرارات وعدم الاتساق القديمة للنظام الجديد، تُفسِد التقارير من اليوم الأول. الحل: طهِّر واحكم البيانات الرئيسية قبل الترحيل، وامتلكها بعد ذلك.
  • التخصيص لتكرار النظام القديم. تغييرات مُخصَّصة لتجنب تغيير العملية تُضخِّم الكلفة وتُدمِّر قابلية الترقية. الحل: تبنَّ القالب المعياري؛ غيِّر العملية، لا البرنامج.
  • تشغيل ERP كمشروع تقنية معلومات. معاملته كتبديل تقنية تُجوِّع التغيير، التدريب، وجهد إعادة تصميم العملية. الحل: شغِّله كبرنامج تغيير أعمال بإدارة تغيير حقيقية (الموضوع 8.1).
  • انطلاق انفجاري كبير متفائل. جداول زمنية مضغوطة وتحويل واحد يُحوِّلان مشاكل عادية لأزمات علنية. الحل: تدرَّج حيث ممكن، ولا تُبادِل أبدًا الجاهزية بموعد.
  • تكاملات معطلة. تغذية جدولة-إلى-رواتب أو شراء-إلى-دفتر غير مُختبَرة تدفع للناس بشكل خاطئ أو تكسر التصالح. الحل: ارسم، امتلك، واختبر من طرف لطرف كل واجهة.
  • جداول بيانات ظِلّية تنجو. تستمر الحلول المحلية جنبًا إلى جنب مع ERP، تُعيد تشتيت البيانات. الحل: اجعل ERP نظام السجل الوحيد وأخرِج الظِلّيات من الخدمة.

نموذج النضج#

البُعد ابدأ طوّر وحِّد المعايير أدِر نسِّق
مشهد النظام أنظمة مكتب خلفي مُتقادِمة ومتعددة وغير مُتصِلة المالية الجوهرية مُوحَّدة؛ الموارد البشرية/الشراء منفصلان ERP مُدمَج كنظام سجل ERP مُدمَج مع صحة مشهد النظام وأداء المنصة مُتتبَّعين مقابل أهداف خدمة ERP سحابي على منصة مشتركة/اتحادية، مُرقّاة باستمرار
البيانات الرئيسية غير مملوكة، مُكرَّرة، غير مُتَّسِقة مُطهَّرة للانطلاق، ثم تنجرف مُحكَمة بملكية واضحة الجودة مقاسة مقابل مؤشرات أداء رئيسية مُحدَّدة، بضوابط رعاية مضمونة مُدارة بنشاط بمقاييس جودة ورعاية
التكامل إعادة إدخال يدوي بين الأنظمة واجهات نقطة-لنقطة، هشة واجهات مرسومة، مُختبَرة، ومملوكة واجهات مُراقَبة بمؤشرات تصالح وتنبيه عند الفشل تدفقات بيانات مُؤتمَتة، مُراقَبة، ومُصالَحة
انضباط التنفيذ بقيادة تقنية المعلومات، لا إدارة تغيير بنية برنامج لكن جهد تغيير ضعيف برنامج تغيير أعمال بانطلاق مُتدرِّج التسليم والانطلاق مُحكَمان مقابل مقاييس فوائد، جاهزية، وخطر تبني قالب مُوحَّد؛ الترقيات روتينية
طرق العمل جداول بيانات ظِلّية في كل مكان بعض العمليات داخل النظام العمليات مُحاذاة لنظام سجل ERP أداء العملية والتبني مُتتبَّعان مقابل مؤشرات أداء رئيسية وضوابط تقارير بيانات ERP تقود التخطيط، التكليف، والقرارات

قائمة التحقق#

  • دليل الحسابات، بيانات الموردين، العناصر، والموظفين الرئيسية مُطهَّرة ومُزال ازدواجها قبل الترحيل.
  • ملكية وحوكمة البيانات الرئيسية المستمرة مُعيَّنتان ومُموَّلتان.
  • التنفيذ مُحدَّد النطاق ومُزوَّد بالموارد كبرنامج تغيير أعمال، لا مشروع تقنية معلومات.
  • التخصيص مُقلَّل؛ يُتبنّى قالب المورد أو الاتحاد المعياري للعمليات السلعية.
  • كل تكامل (جدولة، رواتب/ESR، سريري/صيدلي، مصرفي، تحليلات) مرسوم، مملوك، ومُختبَر من طرف لطرف.
  • نهج الانطلاق (مُتدرِّج مقابل انفجاري) مُختار على الجاهزية، لا على موعد مفروض.
  • تحويل البيانات، التشغيل المتوازي، التصالح، وفترة عناية مُكثَّفة مُخطَّطة ومُزوَّدة بالموظفين.
  • إدارة التغيير، التدريب، وإعادة تصميم العملية مُزوَّدة بالموارد صراحة (انظر الموضوع 8.1).
  • خيارات الخدمات المشتركة وERP السحابي مُقيَّمة على مفاضلاتها الحقيقية للتوحيد-مقابل-المرونة.
  • ERP مُؤسَّس كنظام السجل الوحيد، وجداول البيانات الظِلّية مُخرَجة من الخدمة.

المصادر الرئيسية#

  • NHS Shared Business Services (NHS SBS) — the national Oracle-based finance and procurement shared service for NHS organisations. https://www.sbs.nhs.uk/
  • Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — scale of the national NHS finance platform. https://www.oracle.com/uk/
  • NHS North of England Commissioning / NEP consortium — templated Oracle Cloud ERP for NHS members. https://nepcloud.nhs.uk/
  • Unit4, Public sector and healthcare ERP — ERP for NHS trusts, local authorities, and universities. https://www.unit4.com/industries/public-sector-software
  • HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — finance processes ERP underpins. https://www.hfma.org.uk/
  • NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with. https://www.electronicstaffrecord.nhs.uk/
  • See also الموضوع 5.2 — Programme Management, الموضوع 5.3 — Enterprise Project Portfolio Management, and الموضوع 8.1 — Change Management.

المراجع#

  1. Enterprise resource planning — ويكيبيديا — https://en.wikipedia.org/wiki/Enterprise_resource_planning
  2. System of record — ويكيبيديا — https://en.wikipedia.org/wiki/System_of_record
  3. Master data management — ويكيبيديا — https://en.wikipedia.org/wiki/Master_data_management
  4. Chart of accounts — ويكيبيديا — https://en.wikipedia.org/wiki/Chart_of_accounts
  5. Payroll — ويكيبيديا — https://en.wikipedia.org/wiki/Payroll
  6. Procure-to-pay — ويكيبيديا — https://en.wikipedia.org/wiki/Procure-to-pay
  7. Software as a service — ويكيبيديا — https://en.wikipedia.org/wiki/Software_as_a_service
  8. Shared services — ويكيبيديا — https://en.wikipedia.org/wiki/Shared_services
  9. Data migration — ويكيبيديا — https://en.wikipedia.org/wiki/Data_migration
  10. Change management — ويكيبيديا — https://en.wikipedia.org/wiki/Change_management
  11. Business process re-engineering — ويكيبيديا — https://en.wikipedia.org/wiki/Business_process_re-engineering
  12. Electronic health record — ويكيبيديا — https://en.wikipedia.org/wiki/Electronic_health_record
  13. NHS Shared Business Services — ويكيبيديا — https://en.wikipedia.org/wiki/NHS_Shared_Business_Services
  14. NHS Shared Business Services — the national Oracle-based finance and procurement shared service for NHS organisations — https://www.sbs.nhs.uk/
  15. NHS Shared Business Services with Oracle Fusion Cloud Applications — Oracle — https://www.oracle.com/uk/
  16. Public sector and healthcare ERP — Unit4 — https://www.unit4.com/industries/public-sector-software
  17. Introductory Guide to NHS Finance — HFMA — https://www.hfma.org.uk/
  18. NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with — https://www.electronicstaffrecord.nhs.uk/

تعديل هذه الصفحة على GitHub — الكتاب هو مصدر الحقيقة؛ هذا الموقع يعرضه.