حساب التكلفة لكل استخدام في (Power BI) باستخدام تحليلات (Alma) ولمسة من بايثون

المقدمة والخلفية:

تُتخذ قرارات المجموعات الكبرى في مكتبات جامعة أوريغون (UO) من قِبل مجموعة مديري المجموعات، التي تتألف من ممثلين عن التزويد والموارد الإلكترونية والمكتبيين المتخصصين في الموضوعات وخدمات الإتاحة. وفي مواجهة احتمال تخفيض كبير في ميزانية المجموعات في السنة المالية 2022، بدأت هذه المجموعة تتباحث في كيفية تحديد الدوريات التي ستُلغى. وطُرحت التكلفة لكل استخدام (Cost Per Use, CPU) بوصفها نقطة انطلاق لاتخاذ قرارات مستندة إلى البيانات.

وتاريخيًا في جامعة أوريغون، كانت بيانات الاستخدام تُخزَّن في جداول بيانات مُعدّة يدويًا تضم بيانات مجمّعة من جميع الموردين، في حين كانت بيانات التكلفة تُخزَّن في (Alma). وحين كانت إلغاءات الحزم الصغيرة مطروحة في السنوات السابقة، كانت التكلفة لكل استخدام تُحسب يدويًا لتلك العناوين. وكان من المفهوم أن يتردد الموظفون الذين يتعاملون مع جداول البيانات في حساب التكلفة لكل استخدام يدويًا لأكثر من 78,000 صف من أرقام الاستخدام في إحصاءات الموردين المجمّعة آنذاك.

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

مراجعة الأدبيات:

كما لاحظت هاركر (Harker) ([1] 2022, 355)، فإن مقياس التكلفة لكل استخدام «قد أصبح منتشرًا في كل مكان ويكاد يكون عالميًا في تقييم الموارد، ولا سيما الموارد المتجددة مثل الدوريات وقواعد البيانات»، لأنه مباشر وسهل الاستيعاب. وتتناول معظم المقالات التي تناقش التكلفة لكل استخدام جوانب الخلاف حول ما إذا كان ينبغي استخدامها أصلًا، أو المقاييس والإجراءات المحددة التي ينبغي إدراجها في تحليل التكلفة لكل استخدام، أو القيود التي تعتري المقاييس المحددة المستخدمة حاليًا (مثل (COUNTER 5)).

وأقل شيوعًا منها المقالات التي تصف التفاصيل التقنية لمسارات قابلة لإعادة الإنتاج لجمع تحليلات التكلفة لكل استخدام وتوظيفها. وقد يعكس ذلك صعوبات استخدام البرمجيات المملوكة (مثل (Power BI)) للعمل على بيانات تحميها اتفاقيات الترخيص. وكانت المقالات القليلة التي تناولت مسائل الوصول التقني مفيدة جدًا لمشروعنا. فقد قدّم بيش (Pesch) ([2] 2015) دليلًا تمهيديًا أساسيًا لاستخدام (SUSHI) و(COUNTER)، في حين وصفت بوردمان وتومبسون (Boardman and Thompson) ([3] 2022) استخدام تحليلات (Alma) للاستعلام برمجيًا عن واجهات برمجة التطبيقات (APIs) الخاصة بـ(SUSHI) وتمثيل إحصاءات (Counter) بصريًا، فوثّقتا أن ذلك ممكن وإن لم تشاركا التفاصيل التقنية اللازمة لتنفيذ المشروع. وتسعى هذه الورقة إلى سد فجوة في الأدبيات العلمية بتقديم وصف واضح، خطوة بخطوة، لما قمنا به، قد يفيد الآخرين.

مقاربات لبناء المسار:

في النسخة الأولى لهذا المشروع، أنشأنا جدولًا للتكلفة لكل استخدام في (Excel) بدمج جداول بيانات الاستخدام والتكلفة.

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

ثم قررنا استيراد ملفات (Excel) إلى (Microsoft Power BI).

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

وكانت الخطوة التالية جمع إحصاءات الاستخدام ديناميكيًا بالاستعلام عن واجهات (SUSHI) لدى موردينا. وجرّبنا إجراء استدعاءات (SUSHI) مباشرة من داخل (Power BI)، ونجحنا في تشغيل العملية مع جدول ثابت، لكننا لم نجد طريقة لإضافة استخدام الشهر التالي باستمرار على نحو يخزّن البيانات تخزينًا صحيحًا.

وعلمنا أن هذا قيد مقصود في برمجية (Power BI)، التي لم تُصمَّم لتعمل مصدرًا للبيانات، بل لتستمد البيانات من مصادر أكثر ثباتًا مثل قواعد بيانات (SQL). وكان سيتعين علينا تخزين البيانات خارج (Power BI)، وهو ما يُفقد إجراءَ استدعاءات (SUSHI) من داخل (Power BI) أناقتَه.

واستقر بنا الأمر أخيرًا على استخدام أداة حصاد (SUSHI) في (Alma) لجمع بياناتنا وتخزينها.

صُمِّم (Alma) لحصاد بيانات الاستخدام وتخزينها معًا، وكنا نعلم أن بإمكاننا استخراج المعلومات من (Alma) باستخدام قاعدة بيانات (SQL) في تحليلات (Alma). لكن إن أردنا تقريرًا ديناميكيًا بالكامل، فسيتعين علينا عندئذ الاستعلام عن (Alma) لاسترجاع تقارير التكلفة والاستخدام شهريًا. واستكشفنا الاستعلام عن واجهة برمجة تطبيقات تحليلات (Alma) باستخدام (Power Query) (M) داخل (Power BI)، لكننا وجدنا تتبُّع الأخطاء وإصلاحها صعبًا جدًا.

فقررنا بدلًا من ذلك استخدام نص برمجي بلغة بايثون مضمَّن في (Power BI) للاستعلام عن واجهة برمجة تطبيقات التحليلات لاسترجاع بيانات التكلفة والاستخدام معًا. ثم استخدمنا (Power BI) لتحويل البيانات، وحساب التكلفة لكل استخدام وتمثيلها بصريًا، وتوزيع لوحة المعلومات (dashboard) الخاصة بنا على أصحاب المصلحة الداخليين.

وفي هذا النموذج النهائي، تُنشأ حسابات واجهة (SUSHI) لأكبر عدد ممكن من الموردين في (Alma)، الذي يحصد تقارير (tr_j1) شهريًا. وتُنشأ تقارير في تحليلات (Alma) لالتقاط إحصاءات التكلفة والاستخدام. وتسترجع نصوص بايثون المضمَّنة في استعلام (M) في (Power BI) كل تقرير عبر واجهة برمجة تطبيقات، وتمر على البيانات في حلقة تكرارية باستخدام رمز الاستئناف (resumption token) (المطلوب للبيانات التي تزيد على 1,000 صف). ويجلب كود بايثون مجموعة البيانات الكاملة في كل مرة نريد تحديثها، وهو ما يمكننا فعله بمجرد الضغط على زر (Refresh) في (Power BI). ويبسّط مزيد من كود (M) البيانات. ثم يدمج كود (DAX) البيانات من مجموعتي البيانات لحساب التكلفة لكل استخدام. وتُستخدم أدوات التمثيل البصري في (Power BI) لإنشاء لوحة معلومات يمكن مشاركتها مع أصحاب المصلحة.

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

لوحة المعلومات في صورتها المرئية:

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

تعريف التكلفة لكل استخدام:

لأن هذا العمل يختبر جدوى المسار التقني (proof of concept)، فإنه يستخدم تعريفًا مبسطًا للتكلفة لكل استخدام: المبلغ السنوي المدفوع مقابل المنتج مقسومًا على عدد مرات الاستخدام المسجلة في تقارير (COUNTER) من نوع (tr_j1)، مع احتساب استخدام الدوريات فقط واستبعاد قواعد البيانات والكتب الإلكترونية. ويتفق هذا الحساب مع صيغة (Electronic Max CPU) الواردة في الملحق. ولا نعالج، مثلًا، مسائل مقالات الوصول المفتوح التي ناقشها جابيلي (Jabaily) ([4] 2020) أو التي يعالجها منتج (Unsub) [5]. ومع ذلك، نأمل أن يكون هذا المسار أساسًا لتحليلات أكثر متانة، نظرًا إلى قدرة (Power BI) على تجميع البيانات من مصادر متنوعة وتمثيلها بصريًا. فقد نعدّل الحساب مستقبلًا لمراعاة الإتاحة بالوصول المفتوح، أو ندرج الكتب الإلكترونية وقواعد البيانات، أو نضيف تتبع الدوريات التي يستشهد بها أعضاء هيئة التدريس وطلبة الدراسات العليا لدينا أو ينشرون فيها.

الافتراضات والقيود:

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

وثمة فجوات في البيانات حين لا يوفر الناشرون إتاحة (SUSHI)، أو تقارير بصيغة (COUNTER 5)، أو لا يوفرونها في الوقت المناسب. يضاف إلى ذلك أننا لم نملأ بعدُ على نحو منهجي الفجوات بين بداية وجود (COUNTER 5) وبدء حصاد (SUSHI) في نسختنا من (Alma). وفي بعض الأحيان لا تتطابق العناوين أو أرقام (ISSN) تطابقًا تامًا، أو يكون لدينا استخدام مُبلَّغ عنه من منصات متعددة. وقد أزلنا منصتي التجميع (Gale) و(JSTOR) من بياناتنا، وليس لدينا حاليًا طريقة لتقييم هذا الاستخدام. ولا ندرج الاستخدام الورقي لمجموعتنا في الوقت الحالي. ففي نموذج (Excel) الأولي كان الاستخدام الورقي منخفضًا جدًا، ولم يكن الاستخدام لأعداد حديثة، فقررنا أن إدراج الاستخدام الورقي لن يضيف قيمة إلى نموذجنا.

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

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

المناقشة والعمل المستقبلي:

أعددنا هذا النموذج باستخدام تقرير (tr_j1) وحده، وبمجرد أن نكتسب بعض الخبرة في الرجوع إلى النموذج للمساعدة في قرارات الاستبعاد (deselection)، نخطط لإضافة مزيد من أنواع التقارير. ونحن مهتمون بإضافة بيانات الاستخدام التاريخية بتحميل إحصاءات (COUNTER 4) إلى (Alma) لإضافة مزيد من السنوات إلى النموذج. وقد ننظر أيضًا في حسابات إضافية تتجاوز التكلفة لكل استخدام قد تكون مفيدة لاحتياجاتنا في تقييم المجموعات. وبالطريقة التي كُتبت بها هذه التقارير، لا ينبغي أن نضطر إلى إجراء تغييرات كبيرة ما لم تحدث تغييرات جوهرية في (COUNTER) أو في تحليلات (Alma). وهذا مقصود، كي نتمكن من إبقاء المسار عاملًا بأقل قدر ممكن من الصيانة.

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

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

الملحق أ:

دليل خطوة بخطوة لبناء مسار من (Alma) إلى (Power BI) لحساب التكلفة لكل استخدام:

1. تحديد المتطلبات المسبقة:

• لتكرار مقاربتنا، ستحتاج إلى إمكانية الوصول إلى (Alma) وتحليلات (Alma) و(COUNTER 5) وواجهات برمجة التطبيقات و(SUSHI) وبايثون و(Power BI)، ومعرفة بها، وبعض المهارات فيها.
• يتطلب (Power BI Desktop) حاسوبًا شخصيًا بنظام (Windows).
• من المفيد أن تكون لديك معرفة أولية بالبرمجة بلغة (SQL) في تحليلات (Alma) وبلغتي (M) و(DAX) في (Power BI)، لإجراء تعديلات تناسب احتياجاتك ومسار عملك بصورة أفضل.

2. إعداد الموردين بواجهة (SUSHI) في (Alma) مع تفعيل أنواع تقارير (tr_j1):

• اتبع قسم «(Managing SUSHI Accounts)» من وثائق (Ex Libris) «(Managing COUNTER-Compliant Usage Data)». [م1]
• أعِدّ الموردين يدويًا في (Alma).
• حدد أسماء المستخدمين وكلمات المرور الإدارية لمزودي المحتوى، والطبقة التالية من بيانات الاعتماد الخاصة بـ(SUSHI): معرّف العميل (customer ID)، ومعرّف طالب البيانات (requestor ID)، وأحيانًا مفتاح واجهة برمجة التطبيقات (API key). يُرجى الانتباه إلى ما يأتي:
• يمكن العثور على بعض بيانات اعتماد (SUSHI) في موقع مزود المحتوى، ولا يمكن العثور على بعضها الآخر. وقد يلزم الاتصال بخدمة العملاء للحصول عليها.
• تغيّرت بيانات اعتماد كثيرة في أثناء الانتقال من (COUNTER 4) إلى (COUNTER 5).
• يمكن أن تتغير بيانات الاعتماد في أي وقت دون إشعار.
• حدد عنوان (URL) الأساسي لسلسلة واجهة (SUSHI). يُرجى الانتباه إلى ما يأتي:
• الموردون الشائعو الاستخدام مُعَدّون مسبقًا في نسخة (Alma) الخاصة باتحادنا، وكانت عناوين (URL) الأساسية صحيحة في أغلب الأحيان.
• إن لم يعمل حقل «(Vendor URL)» في (Alma)، فجرّب حقل «(Override URL)». وقد يلزم إضافة «/(sushi)» أو «/(sushi)/» أو «/(reports)» أو «/(reports)/» إلى نهاية عنوان (URL) الأساسي لسحب التقرير بنجاح.
• يُكتب معرّف «(Requester)» بحرف «(e)» في (Alma)، ويُكتب «(Requestor)» بحرف «(o)» في سلاسل واجهة (COUNTER). وهذه تفصيلة مهمة إذا اختبرت سلاسل الواجهة في المتصفح.
• تحت «(Usage Report Types)» في (Alma)، انقر «(Add Report Type)» لرؤية قائمة أنواع التقارير. واختر (tr_j1) لتتبع مثالنا.
• اختر «(Test with Response)» لاختبار ما إذا كان الاتصال يعمل، ولرؤية مثال على الحصاد الذي يعيده (Alma).

3. إعداد الحصاد التلقائي لـ(SUSHI) في (Alma):

• اتبع قسم «(Managing SUSHI Harvesting)» من وثائق (Ex Libris) «(Managing COUNTER-Compliant Usage Data)». [م1]
• بمجرد إعداد الموردين واختبارهم والتحقق منهم، فعّل الحصاد التلقائي.
• اختر تاريخًا للحصاد.
• بعد تجربة تواريخ مختلفة من التواريخ المعدّة مسبقًا في (Alma)، استقر بنا الأمر على اليوم الثامن عشر من الشهر لجمع تقارير الاستخدام الجديدة.
• فعّل وظيفة تلقي تقرير حصاد (SUSHI) الشهري بالبريد الإلكتروني بعد اكتمال الحصاد.
• سيُدرج تقرير حصاد (SUSHI) الشهري المحاولات المكتملة والفاشلة، مع الأخطاء. ومعالجة الأخطاء موصوفة في بداية قسم «الصيانة المستمرة».
• يشير هذا البريد الإلكتروني إلى أن نموذج (Power BI) يمكن تحديثه لاستقبال إحصاءات الاستخدام المحدّثة، كما هو موصوف في نهاية قسم «الصيانة المستمرة».

4. إنشاء تقرير في تحليلات (Alma) عن التكاليف:

• جرّب التقارير الجاهزة (out-of-the-box) من (Ex Libris) أو أنشئ تقريرك الخاص. ولم نجد تقريرًا جاهزًا يلبي احتياجاتنا المحددة.
• لتتبع مثالنا، استخدم (Library Name) و(Fiscal Period Description) و(Transaction Expenditure Amount) و(Fund Code) و(Title) (Normalized) و(ISSN) وتفاصيل (PO Line Reference) بما فيها (Item Description)، وصفِّ على الاستمرارية «(continuous)» والحالة «(active)».
• أعطانا حقل (Item Description) أفضل النتائج لمطابقة العناوين مع (Normalized Title) في المجال الموضوعي (Usage Data) في التحليلات، لكن ذلك قد يختلف بحسب مسار عمل الفهرسة لديك.
• عدّل صيغة العمود (Item Description) لتحويل جميع أوصاف المواد إلى أحرف صغيرة، باستخدام (LOWER)("(PO Line)"."(Item Description)")، للبدء في توحيد صيغ البيانات. وتُزال أدوات التعريف الاستهلالية لاحقًا في (Power BI). ويمكن أيضًا تحويل الأحرف إلى صغيرة في (Power BI) لإجراء جميع خطوات التوحيد في بيئة واحدة، وهو خيار قد تفضله إن لم تكن صيغ التحليلات مألوفة لديك.
• اكتب تقريري التحليلات كليهما بحيث تُعرض السنة المالية بصيغة «(FY-XXXX)» لتمكين المطابقة بين الجداول.
• اختبر التقرير وعدّله حسب الحاجة بما يلائم بياناتك ومؤسستك.

5. إنشاء تقرير في تحليلات (Alma) عن استخدام (COUNTER 5) من نوع (tr_j1):

• لم نجد تقريرًا جاهزًا يلبي احتياجاتنا المحددة.
• لتتبع مثالنا، استخدم (TR_J1) – (Unique Item Requests) و(TR_J1) – (Total Item Requests) و(Usage Date Fiscal Year) و(Usage Date Year) و(Usage Date Month Key) و(Usage Date Month) و(Usage Date Quarter) و(Normalized Title) و(Normalized ISSN) و(Normalized EISSN) و(Origin ISSN) و(Origin EISSN) و(Normalized Publisher) و(Publisher) و(Normalized Platform) و(Load File COUNTER Report Type).
• يستخدم هذا التقرير العنوان الموحَّد الصيغة، فلا حاجة إلى تحويلات إضافية.
• اكتب تقريري التحليلات كليهما بحيث تُعرض السنة المالية بصيغة «(FY-XXXX)» لتمكين المطابقة بين الجداول.
• اختبر التقرير وعدّله حسب الحاجة بما يلائم بياناتك ومؤسستك.

6. الحصول على أذونات استخدام مفتاح واجهة برمجة تطبيقات تحليلات (Alma) الخاص بالتزويد:

• اعمل مع مطوّر (Alma) في مؤسستك للحصول على الأذونات ومفتاح واجهة برمجة التطبيقات لاستخدام واجهة «(Retrieve Analytics Report)»، مع حفظ الأسرار في شبكة مطوري (Alma) (Alma Developer Network).
• اتبع نصيحة غاندالف: «احفظه سرًّا، واحفظه آمنًا.» [م2]
• ابنِ المسار لكل تقرير من تقارير التحليلات باستخدام عنوان (URL) الجذري، ومسار تقرير التحليلات، ومفتاح واجهة برمجة التطبيقات الخاص بالتزويد.
• يبدأ مسارنا بـ رابط المصدر لكنه قد يختلف بحسب نسخة (Alma) لديك.
• افتح تقرير التكلفة أو تقرير الاستخدام في التحليلات. وفي المتصفح، انسخ الجزء من رابط تقرير التحليلات الذي يبدأ بعد علامة المساواة. وأضف النص المنسوخ بعد علامة المساواة في المسار الذي تبنيه. ولاحظ أنه عند النسخ واللصق تُستبدل المسافات الفارغة بـ«%20».
• أضف «&(apikey)=» ثم مفتاح واجهة برمجة التطبيقات الخاص بالتزويد إلى نهاية المسار.
• كرر خطوات بناء عنوان التقرير في قسم الحصول على أذونات واجهة برمجة التطبيقات لبناء عنوان (URL) للتقرير الثاني.
• اختبر كل تقرير.
• ثمة خيارات كثيرة لاختبار واجهات برمجة التطبيقات، منها وضع السلسلة كاملة في المتصفح.
• ومن الطرق الأخرى لاختبار ذلك تعيين الواجهة مصدرًا للبيانات في (Power BI).
• راجع البيانات. إن كانت بياناتك تزيد على 1,000 صف، فستحتاج إلى استخدام رمز الاستئناف لاسترجاع المجموعة الكاملة في (Power BI). ولم نتمكن من تشغيل رمز الاستئناف باستخدام (Power Query) (M) مباشرة، فاستخدمنا نصًا برمجيًا بلغة بايثون لاسترجاع التقرير وتمرير رمز الاستئناف، كما هو موصوف في الخطوة التالية.

7. كتابة نص بايثون للاستعلام عن واجهة برمجة تطبيقات تحليلات (Alma)، مع رموز الاستئناف لاسترجاع أكثر من 1,000 نتيجة:

• بنينا استعلامنا في بايثون على مجموعة موثقة جيدًا من التعليمات حول كيفية الاستعلام عن واجهة برمجة تطبيقات (OpenAlex)، أعدها إريك شاريس (Eric Schares) وساندرا ميرز (Sandra Mierz). [م3]
• لا تتردد في نسخ الكود الخاص بنا، وهو متاح في عدة نسخ مختلفة. [م4]
• لأن واجهة برمجة تطبيقات تحليلات (Alma) يمكنها الوصول إلى معلومات المستفيدين، فقد حافظنا على مستوى عالٍ من الأمان. وقد فعلنا ذلك في البداية بإنشاء نص بايثون متتبَّع في (GitHub) يستخدم مكتبة (configparser) لجلب أسرارنا (مفتاح واجهة برمجة التطبيقات ومسارات التقارير) من ملف (config.ini) منفصل غير متتبَّع في (GitHub).
• نوصي باختبار كود بايثون خارج (Power BI) باستخدام مفسّر بايثون المفضل لديك مع مصحح أخطاء (debugger)، لأن (Power BI) لا يتضمن مصحح أخطاء مدمجًا لبايثون.
• غير أنه لأن (Power BI) لا يسمح لكود بايثون بالرجوع إلى ملفات أخرى (مثل ملف (config.ini))، فقد أنشأنا يدويًا نسخة لم تعد تستخدم (configparser) للإحالة إلى ملف منفصل يحوي الأسرار، بل تتضمن جميع الأسرار مكتوبة صراحةً (hard coded) في نص بايثون. وفي القسم التالي، نناقش كيف أضفنا هذا النص المكتوبة أسراره صراحةً إلى (Power BI)، وكيف عدّلناه ليصبح كل سر معاملًا (parameter) في (Power BI).

8. إنشاء اتصال (Power BI) بتقريري التكلفة والاستخدام باستخدام نص بايثون:

• لإضافة نص بايثون إلى (Power BI)، اتبع أولًا التعليمات الواردة في وثائق (Microsoft) لتثبيت بايثون على الحاسوب المكتبي (يُوصى ببيئة افتراضية)، واستورد أي مكتبات بايثون لازمة (استخدمنا (pandas) و(xml.etree.ElementTree) و(requests) و(time))، واضبط وصول بايثون في (Power BI)، وفعّل الأذونات. وحتى وقت كتابة هذه السطور، يجب ضبط جميع مصادر بيانات بايثون على «(Public)» لتعمل مع خدمة (Power BI).
• بمجرد ضبط الأذونات، اختر في (Power BI Desktop) «(Get Data)» ثم مرّر إلى الأسفل واختر «(More)» لفتح نافذة جديدة. ومرّر إلى الأسفل واختر «(Python script)» ثم انقر «(Connect)». والصق نص بايثون في مربع النص، ثم انقر «(OK)». وإن عمل النص على نحو صحيح، فستُطالَب بتحميل البيانات في جدول (Power Query). وستكون أولى الخطوات المطبَّقة لهذه البيانات «(Source)»، وتتيح لك أيقونة الترس على يمين الخطوة فتح نص بايثون وعرضه كما أُدخل في الأصل.
• لرؤية نص بايثون كما يظهر محمَّلًا في نص (Power Query) (M)، افتح «(Advanced editor)» في شريط (Power Query). ولاحظ أن (Power BI) قد ترجم النص بتغليفه بأمر للتشغيل في بايثون وإضافة #(lf) في موضع كل نهاية سطر في نص بايثون الأصلي.
• نوصي بتحويل الأسرار المكتوبة صراحةً (مفتاح واجهة برمجة التطبيقات ومسار التقرير) إلى «(Parameters)» في (Power BI) يمكن تحديثها بسهولة أكبر من قِبل الأقل إتقانًا لبايثون أو (M). ولفعل ذلك، اتبع أولًا تعليمات (Microsoft) لإنشاء معاملاتك. وقد أنشأنا لكودنا أربعة معاملات: (url) و(api_key) و(use_data_path) و(cost_data_path). واحرص على تحديد نوع البيانات «(Text)» وإدخال كل معامل محاطًا بعلامتي تنصيص. فمثلًا، سيبدو المعامل (api_key) على نحو يشبه “(k3lk2ke4536kjklk4)” (مع علامتي التنصيص).
• عد الآن إلى نافذة «(Advanced editor)» في (Power Query) واستبدل مفتاح واجهة برمجة التطبيقات المكتوب صراحةً، الذي سيكون على نحو يشبه “(k3lk2ke4536kjklk4)”، بـ“& (api_key) &”، حيث (api_key) هو اسم المعامل، ويبدأ الكود البديل وينتهي بعلامتي تنصيص مزدوجتين.
• لرؤية كود بايثون الخاص بنا في سياق (Power BI)، افتح ملف قالب (Power BI) ‏(.pbit) المتاح في مستودعنا على (GitHub)‏، رابط المصدر. [م5]
• إن كانت لديك تقارير مناسبة مُعدّة في تحليلات (Alma)، فأدخل القيم الحقيقية لـ(url) و(api_key) و(use_data_path) و(cost_data_path). وإلا فأدخل قيمة مؤقتة في الحقول، مثل «(test)»، للوصول إلى نموذج (Power BI) واستكشافه. وفي الحالتين، انقر «(Load)».
• قد تحتاج إلى منح (Power BI) إذنًا بتشغيل النص.
• سيحدث تأخير بينما يحاول (Power BI) إجراء استدعاءات واجهة برمجة التطبيقات.
• إن كانت المعاملات تحمل القيمة «(test)»، فسترى نافذة منبثقة تحذر من أخطاء في نص بايثون. امضِ وأغلق مربع الخطأ هذا.
• رغم مزيد من رسائل الخطأ، أنت الآن داخل ملف (Power BI) الخاص بنا ويمكنك استكشاف كل خطوة من خطوات تحويل البيانات لدينا في (Power Query) (M) و(DAX).
• اعثر على كود بايثون باختيار «(Transform Data)» ثم النقر على «(Advanced editor)» لأي من الجدولين (usage_data) أو (cost_data).

ستشرح الخطوات التالية كيف تعاملنا مع بياناتنا بعد استيرادها إلى (Power BI). ويمكنك البحث عن هذه الخطوات في بيئة (Power BI) لتواكب الخطوات الموصوفة.

9. مطابقة بيانات التكلفة والاستخدام على أرقام (ISSN) والعناوين باستخدام لغتي (M) و(DAX):

• بمجرد إنشاء الاتصال، ستلزم إجراء تحويلات في (Power Query) باستخدام لغة (M) لفتح الجداول، وتوحيد صيغ البيانات، وتهيئتها للمطابقة.
• بدءًا ببيانات التكلفة، افتح جداول البيانات بالنقر على الأسهم التي تشير يمينًا ويسارًا في آن واحد، حتى تشير جميع علامات الأعمدة إلى الأسفل وتكون قد تعمّقت وصولًا إلى الأعمدة بحيث تطابق تقرير تحليلات (Alma) عن التكاليف.
• قد تحتاج إلى تغيير أنواع البيانات (مثل تحويل الأرقام إلى عملة)، وإزالة الأعمدة غير اللازمة، وإعادة تسمية الأعمدة لمزيد من الوضوح، وما إلى ذلك، حتى تكون بياناتك مفهومة وتعمل جيدًا في (Power BI). وهذه عملية تفاعلية ستحتاج إلى تكييفها مع بياناتك واحتياجاتك.
• تذكّر أننا حوّلنا (Item Description) إلى أحرف صغيرة في تحليلات (Alma). وفي هذه المرحلة، استخدم كود (M) في (Power Query) لإزالة «(the)» و«(a)» في البداية لمزيد من توحيد الصيغ ومطابقة هذه العناوين مع العناوين التي ستظهر في جدول الاستخدام.

كود إزالة «(the)»:

= Table.ReplaceValue(#"Renamed Columns", each [Title Normalized], each if Text.StartsWith([Title Normalized],"the ") then Text.RemoveRange([Title Normalized],0,4) else [Title Normalized], Replacer.ReplaceText, {"Title Normalized"})

• قد تبقى فروق بين جدول التكلفة وجدول الاستخدام بين «(and)» و«&»، وعلامات الترقيم في وسط العنوان، وفروق أخرى غير معروفة.

يحتوي حقل (ISSN) على أرقام متعددة؛ فقد بلغت ستة أرقام في بعض الحالات، لكننا قررنا أن رقمين يكفيان للمطابقة. لذلك قسمنا العمود باستخدام محدِّد لفصل أول رقمين في عمودين.

كود التقسيم بمحدِّد:

= Table.SplitColumn(#"Replaced Value", "ISSN", Splitter.SplitTextByDelimiter("; ", QuoteStyle.Csv), {"ISSN.1", "ISSN.2"})

• اختياريًا، أضف عمودًا شرطيًا لـ(Fund Code Display)، وجمّع رموز الصناديق في فئات أوسع لجعل هذه المعلومات أيسر استيعابًا على المكتبيين المتخصصين في الموضوعات. ومن واقع تجربتنا، فإن مخطط صناديق التمويل لدينا أعقد مما لدى معظم المكتبات، فقد لا تحتاج إلى هذه الخطوة.
• انتقل إلى بيانات الاستخدام، وافتح جداول البيانات حتى تتعمق وصولًا إلى الأعمدة بحيث تطابق تقرير تحليلات (Alma) عن الاستخدام، كما في خطوة فتح جداول بيانات التكلفة.
• وحّد صيغ العناوين هنا أيضًا، بإزالة «(the)» و«(a)» في البداية حتى تتطابق مع العناوين في جدول التكلفة.
• مرة أخرى، قد تحتاج إلى تغيير أنواع البيانات، وإزالة الأعمدة، وإعادة تسمية الأعمدة، وما إلى ذلك، حتى تكون بياناتك مفهومة وتعمل جيدًا في (Power BI). وهذه عملية تفاعلية ستحتاج إلى تكييفها مع بياناتك واحتياجاتك.
• بالخروج من (Power Query) والانتقال إلى الجداول، يُفترض أن يكون لديك في هذه المرحلة جدول للتكلفة وجدول للاستخدام. ويضم جدول التكلفة لدينا جميع الأعمدة التي بنيناها في تقرير تحليلات (Alma) عن التكلفة، إضافة إلى عمودي (ISSN) المقسومين وعمود (Fund Code Display).
• أنشئ جدولًا ملخِّصًا للاستخدام. فبيانات التكلفة متاحة لكل سنة مالية، في حين أن بيانات الاستخدام متاحة مجمّعة حسب الشهر. ولتبسيط ربط المعلومات، لخّصنا بيانات الاستخدام في جدول جديد وطابقنا الملخصات مع بيانات التكلفة على أرقام (ISSN) أو العناوين الموحَّدة الصيغة.

هذا كود (DAX) لجدول ملخص الاستخدام متضمنًا مجموع (Total Requests):

usage_summary = SUMMARIZE('usage_data', usage_data[Usage Date Fiscal Year], usage_data[Normalized Title], usage_data[Normalized Platform], usage_data[Normalized Publisher], usage_data[Normalized EISSN], usage_data[Normalized ISSN], "Total Requests", SUM(usage_data[Total Requests]))

• بعد إنشاء جدول ملخص الاستخدام، طابق على (ISSN) والعنوان.

بدأنا بـ(ISSN1) من جدول التكلفة وطابقناه مع (Normalized EISSN) من جدول الاستخدام. وهذا كود (DAX):

ISSN1 by Normalized EISSN = CALCULATE (SUM ( 'usage_summary'[Total Requests] ), FILTER ( 'usage_summary', AND(AND('usage_summary'[Normalized EISSN] = 'cost_data'[ISSN1], 'usage_summary'[Usage Date Fiscal Year]='cost_data'[Fiscal Period Description]), IF(AND('cost_data'[ISSN1] = "", usage_summary[Normalized EISSN] = ""), FALSE, TRUE)))

• أنشأنا عمودًا جديدًا لـ(ISSN2 by Normalized EISSN)، وهكذا، إضافة إلى (Title by Title).
• بسبب عدم انتظام البيانات، اخترنا حساب التكلفة لكل استخدام بطريقة تقريبية (fuzzy) باستخدام أغلى سنة وسنة أعلى استخدام. ولن يكون الحساب دقيقًا لبيانات سنة بعينها. ولأن هذه المعلومات مقصود بها اكتشاف الحالات الشاذة، فإن هذا المستوى من التفصيل يكفي لاحتياجاتنا. ولحساب التكلفة لكل استخدام، أضفنا أعمدة لأقصى استخدام وأقصى تكلفة لكل استخدام:

(Electronic Use Max):

Electronic Use MAX = ROUND(MAX('cost_data'[Title by Title],MAX(MAX('cost_data'[ISSN1 by Normalized EISSN],'cost_data'[ISSN1 by Normalized ISSN]),MAX('cost_data'[ISSN2 by Normalized EISSN], 'cost_data'[ISSN2 by Normalized ISSN]))),0)

• الغرض من استخدام الدالة (ROUND) حل المشكلات الناجمة عن كسور الاستخدام.

(Electronic Max CPU):

Electronic Max CPU = IF([Electronic Use MAX]=0,0,'cost_data'[Transaction Expenditure Amount]/[Electronic Use MAX])

• إدراكًا لأن استعارة المواد خيار متاح أيضًا في المكتبات، أدرجنا صيغة لـ(Cost Beyond ILL Threshold) (التكلفة بعد تجاوز عتبة الإعارة بين المكتبات)، وعمودًا يبين ما تعنيه تلك الصيغة من حيث النظر في الإعارة بين المكتبات بدلًا من الاشتراك.

هذه صيغتنا لـ(Cost Beyond ILL Threshold)، على افتراض أن الوثائق عبر (Reprints Desk) تكلف 35 دولارًا وأن بإمكاننا طلب المادة 20 مرة قبل أن نضطر إلى الدفع مقابلها [م5]:

Cost Beyond ILL Threshold = IF('cost_data'[Electronic Use MAX]-20<0,0, ('cost_data'[Electronic Use MAX]-20)*35)

عمود (Consider ILL) عبارة بسيطة قيمتها صواب/خطأ (True / False):

ConsiderILL = IF(AND('cost_data'[Cost Beyond ILL Threshold] < 'cost_data'[Transaction Expenditure Amount],cost_data[Electronic Use MAX] > 0 ), TRUE, FALSE)

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

ILL_vs_subscription = SUMMARIZE('usage_summary', usage_summary[Normalized Title], usage_summary[Normalized Platform], usage_summary[Normalized Publisher], usage_summary[Normalized EISSN], usage_summary[Normalized ISSN], "Max Yearly Requests", MAX(usage_summary[Total Requests]))

10. إنشاء تصويرات بصرية مبنية على التكلفة والاستخدام:

• كان الغرض من كل تلك المعالجة للبيانات أن نتمكن من إعداد تصوير بصري للتكلفة لكل استخدام، والآن بعد إنجاز كل ذلك العمل الشاق، يصبح التمثيل البصري مباشرًا نسبيًا. فللتكلفة لكل استخدام اخترنا مخططًا شريطيًا مكدسًا، واستخدمنا (Title Normalized) للمحور الصادي ومجموع (Electronic Use Max CPU) الوارد في قسم مطابقة بيانات التكلفة والاستخدام للمحور السيني، وأضفنا (Fund Code Display) (الذي اختصرناه إلى (Fund)) مفتاحًا للمخطط (Legend). وأضفنا مقسِّمات (slicers) لـ(Fund) و(Fiscal Year). ويمكن تصفية العرض بهذه المقسِّمات، أو البحث فيه حسب العنوان.
• لنظرة أقرب إلى بيانات الاستخدام، أنشأنا في علامة التبويب الثانية جدولًا مستمدًا من (Normalized Title) و(Total Requests) و(Usage Data Fiscal Year) في جدول (Usage Summary)، وأضفنا مقسِّمًا لـ(Fund). ويمكن تصفية هذا الجدول حسب الصندوق أو البحث فيه حسب المنصة أو الناشر أو العنوان.
• العرض الثالث جدول بالعناوين التي قد يكون الحصول عليها عبر الإعارة بين المكتبات أرخص من الاشتراك فيها، بناءً على أنماط الاستخدام ومتوسط تكلفة الإعارة بين المكتبات.
• علامة التبويب الأخيرة صفحة «حول» (About)، تغطي أبرز ما تتضمنه البيانات وما لا تتضمنه، والقيود المعروفة، ونظرة عامة على العملية.

11. نشر لوحة المعلومات/التقرير على الويب في (Power BI) لمشاركتها مع الزملاء:

• في تطبيق (Power BI) السحابي، أنشئ مساحة عمل (Workspace) ستشارك فيها النموذج.
• سمِّ مساحة العمل، وصِفها، وأضف الأشخاص الذين تريد أن يتاح لهم الوصول إليها.
• في (Power BI Desktop)، انقر «(Publish)» واختر مساحة العمل التي تريد رفعه إليها.
• انتقل إلى التقرير في مساحة العمل ثم انقر زر «(Share)» لمشاركة التقرير مع الزملاء.

12. الصيانة المستمرة:

• حدّث باستمرار أسماء المستخدمين وكلمات المرور لدى الموردين، وبيانات اعتماد الحصاد، ومفاتيح واجهات برمجة التطبيقات، والتغييرات في المنصات وعناوين (URL) الأساسية حسب الحاجة.
• ثمة أخطاء متنوعة يجب معالجتها في تقرير حصاد (SUSHI) الشهري، تتراوح بين عدم توافر تواريخ استخدام المورد بعد، والإخفاق في الاتصال، واسترجاع تقارير غير مرغوب فيها. ومن المفيد أن يُرسَل تقرير حصاد (SUSHI) الشهري من (Alma) بالبريد الإلكتروني إلى الشخص الذي يدير الحسابات لتحديد الأخطاء وتتبعها وإصلاحها.
• أخطاء (SUSHI) موصوفة من قِبل (Project Counter). [م6]
• أخطاء (Alma) / (SUSHI) موصوفة وصفًا جيدًا من قِبل (CARLI). [م7]
• أضف موردين جددًا عند تفعيلهم تقارير (COUNTER 5).
• شهريًا، بعد أن يجري (Alma) حصاد (SUSHI)، حدّث البيانات في (Power BI).
• افتح نموذج (Power BI) في (Power BI Desktop).
• انقر «(Refresh)» لجلب بيانات التكلفة المحدّثة وإحصاءات الاستخدام معًا.
• انقر «(Publish)» لاستبدال النموذج المنشور حاليًا بالنموذج المحدَّث.
• انقر «(Save)» لحفظ المصنف المحدَّث.
• ستظهر رسالة منبثقة بشأن استبدال مجموعة البيانات المنشورة حاليًا. وافق، وانقر «(Replace)».

المراجع:

• [م1a][م1b] “Managing COUNTER-Compliant Usage Data”: https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/020Acquisitions/090Acquisitions_Infrastructure/010Managing_Vendors/Managing_COUNTER-Compliant_Usage_Data
• [م2] انظر فيلم «The Lord of the Rings: The Fellowship of the Ring» («سيد الخواتم: رفقة الخاتم»).
• [م3] OpenAlex-CitedReferences: https://github.com/eschares/OpenAlex-CitedReferences
• [م4] متاح في مستودع مشروعنا على GitHub ‏(https://github.com/uodataservices/cost_per_use) ومؤرشف في Zenodo على https://zenodo.org/records/10426231.
• [م5] هذه الصيغة مبنية على صيغة أعدها زميلنا ديفيد كيتشم (David Ketchum)، مدير خدمات الإتاحة في مكتبات جامعة أوريغون.
• [م6] Appendix F: Handling Errors and Exceptions https://www.projectcounter.org/appendix-f-handling-errors-exceptions/
• [م7] Alma SUSHI Harvesting Status Examples https://www.carli.illinois.edu/products-services/i-share/electronic-res-man/sushierror

5. Unsub: https://unsub.org/
3. Boardman, Erika, and Jennifer France Thompson. 2022. “Visualizing COUNTER Metrics with SUSHI: Exploring Alma Analytics for E-Resource Evaluation.” Serials Review, September, 1–3. https://doi.org/10.1080/00987913.2022.2120328.
1. Harker, Karen R. 2022. “The Depths of Cost-per-Use: Historical Context and Applications.” Library Trends 70 (3): 355–86. https://doi.org/10.1353/lib.2022.0000.
4. Jabaily, Matthew J. 2020. “Recalibrating Cost-per-Use: Implications of COUNTER Release 5 and Unsub.” Serials Review 46 (4): 292–99. https://doi.org/10.1080/00987913.2020.1850040.
2. Pesch, Oliver. 2015. “Implementing SUSHI and COUNTER: A Primer for Librarians: Edited by Oliver Pesch.” The Serials Librarian 69 (2): 107–25. https://doi.org/10.1080/0361526X.2015.1063029.