بنية نظم معلومات إدارة الضرائب

بنية النظام

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

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

ينص المعيار العالمي ISO/IEC/IEEE 42010:2011 على التعريف الآتي:

البنية هي “المفاهيم أو الخصائص الأساسية لنظام ما في بيئته والمتجسدة في عناصره، وعلاقاته، ومبادئ تصميمه وتطوره”.

“إن وضع مفهوم لبنية النظام، على النحو المعبَّر عنه في وصف البنية، يساعد في فهم جوهر النظام والخصائص الرئيسية المتعلقة بسلوكه وتكوينه وتطوره، والتي تؤثر بدورها في جوانب مثار اهتمام مثل جدوى النظام، وفائدته، وإمكانية صيانته”[1]

لنضع أولاً قائمة بالأشياء التي لا ننصح بفعلها عند إنشاء بنية لنظام إدارة الضرائب:

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

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

مؤشرات أداء النظام

الأمر الأهم عند تصميم بنية النظام هو تحديد غرض النظام وأهدافه:

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

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

مؤشرات توفر النظام

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

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

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

متطلبات أمن المعلومات

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

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

تأثير بنية النظام القديمة

ا تُؤسَّس بنية النظام من الصفر؛ لأن كل هيئة ضريبية تستخدم منذ فترة طويلة تطبيقات وأنظمة قديمة (أو ما يسمى بالإصدارات السابقة). وإدخال بنية نظام جديدة هو بمثابة إجراء عملية جراحية لقلب نابض بالحياة. ويتطلب النجاح فهمًا عميقًا للبنية الحالية (“كما هي حاليًّا”)، وبنية نظام مستهدفة مصممة بعناية (“كما يجب أن تكون”)، وخطة للتحول لا تعطل العمليات أو تقلل من توفر أنظمة المعلومات الحالية

البرمجيات مفتوحة المصدر أم المملوكة لطرف معين؟

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

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

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

برمجيات النظام

عند اختيار برمجيات النظام وبرمجيات البنية التحتية، يجب مراعاة الأنواع الآتية من التقنيات:

• أنظمة تشغيل الخوادم.
• أنظمة إدارة قواعد البيانات (DBMS) بنوعَيها: الارتباطية (SQL) وغير الارتباطية (NoSQL) فيما يخص مهام المعاملات والمهام التحليلية.
• خوادم الإنترنت.
• خوادم التطبيقات.
• وسطاء الرسائل مع تسليم الرسائل المضمون.
• المصادقة ومنح الصلاحيات وأنظمة أمن المعلومات، بما في ذلك دعم التوقيعات الرقمية أو ما يماثلها.
• أنظمة المحاكاة الظاهرية والتعبئة في حاويات.
• أنظمة مراقبة أداء التطبيقات.

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

	التكنولوجيا	الاختيار
1	أنظمة تشغيل الخادم	RedHat Linux
2	أنظمة إدارة قواعد البيانات الارتباطية	PostgreSQL
3	أنظمة إدارة قواعد البيانات غير الارتباطية(NoSQL)	Apache Hadoop (HDFS, Yarn, HBase) Apache Hive ClickHouse
4	وسيط الرسائل	Apache Kafka
5	خادم الإنترنت	NGINX
6	خادم التطبيقات	Apache Tomcat
7	إدارة الحاويات	Kubernetes
8	مراقبة التطبيقات	Prometheus Zabbix Grafana

يمكننا أن نوصي بالمجموعة الآتية من البرمجيات مفتوحة المصدر التي أثبتت جدواها، والتي تُستخدم في العديد من المشاريع ذات الأحجام المختلفة من حيث عدد المستخدمين، وحجم التخزين، وعدد الطلبات:

إرشادات تصميم بنية النظام

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

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

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

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

---

[1] ISO/IEC/IEEE 42010:2011(En). هندسة النظم والبرمجيات – وصف البنية الهندسية. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:42010:ed-1:v1:en