خلفية:
يتطلب إطلاق برنامج لتحليل البيانات معالجة تحديات تنظيمية وتقنية معًا. ورغم إدراك المكتبات منذ سنوات أهمية البيانات في اتخاذ القرار، قد يصعب تحويل هذا الإدراك إلى ممارسة يومية. وعدم القدرة على إنشاء برنامج متكامل لا ينبغي أن يمنع المبادرات الصغيرة التي تنشأ من الموظفين. ويستطيع أمناء المكتبات ذوو الخبرة التقنية الإسهام في بناء ثقافة تحليل البيانات من خلال مهارات التفكير الحاسوبي: تحديد المشكلة، وجمع البيانات وتنظيمها ومعالجتها، وفهم توحيدها والإحصاء الأساسي (Wing, 2006؛ Weyland, 2009).
غالبًا ما يعرف هؤلاء الموظفون بيانات المعاملات التي تنتجها أنظمة المكتبة، والأسئلة التي يمكن أن تجيب عنها، وكيفية الوصول إليها وتحويلها إلى معلومات مفيدة. ويمكنهم تجاوز نطاق أدوارهم اليومية بالتعاون مع الأقسام التي تحتاج إلى التحليل.
في مكتبات جامعة ولاية كارولاينا الشمالية، تعمل مجموعات مختلفة على تحليل البيانات لدعم القرار. وتلبي بعض الأقسام احتياجاتها بنفسها، بينما يحتاج غيرها إلى المساعدة. ووجدنا أن بيانات منظمة كثيرة تُجمع دون أن تُستثمر بما يكفي، بسبب نقص الوقت والموارد أو معرفة أساليب التحليل أو وضوح الأسئلة المطلوبة. وقد يجهل الموظفون مصادر البيانات المتاحة في أقسام أخرى، أو يجمعون البيانات دون تحديد الغرض منها. كما قد تفتقر البيانات اليدوية إلى توحيد الصيغ اللازمة للتحليل البرمجي.
تركز المقالة على التحليل الكمي لدعم القرارات العملية المتعلقة بمنتجات المكتبة وخدماتها، ولا تتناول إحصاءات جمعية المكتبات البحثية أو إدارة الجودة الشاملة أو قياس جودة الخدمة أو تقدير قيمة المكتبات والقرارات الإدارية العليا. ومن أمثلة الأسئلة: هل يتجاوز الطلب المعروض من الحواسيب والأجهزة المعارة والكتب الدراسية في أوقات محددة؟ وهل يمكن تعديل التوظيف أو ساعات فتح قاعة المجموعات الخاصة ومكاتب المراجع وفق الاحتياج؟ وهل يساعد قياس استخدام وظائف تطبيقات الويب على تحسين تصميمها ومحتواها؟
تفسر البيانات النوعية أسباب الاتجاهات، لكن جمعها وتفسيرها يتطلبان وقتًا كبيرًا. أما البيانات الكمية فقد تتيح تقييمًا مستمرًا قليل المتطلبات؛ إذ يمكن أن يستمر العائد من الجهد الأول لجمعها ومعالجتها مع استثمار إضافي محدود.
البداية وحصر فرص التحليل:
بدأنا بإعداد قائمة بأنشطة جمع البيانات، من خلال مقابلات مع رؤساء الأقسام والموظفين. وقدمت المقابلات صورة عامة ومعلومات موثقة، وكانت في الوقت نفسه مدخلًا للتواصل حول فرص التحليل. وتحولت الوثائق إلى مصفوفة قرار تضم مصادر البيانات وإجابات عن الأسئلة الآتية:
- هل للمصدر أصحاب مصلحة وجهات اتصال تقنية واضحة؟
- هل يستطيع أصحاب المصلحة صياغة الأسئلة التي يريدون الإجابة عنها؟
- هل تجيب البيانات المتاحة عن تلك الأسئلة؟
- ما صيغة البيانات؟ وما كلفة توحيدها وتنظيفها؟
- هل يفيد التحليل طرفًا أو عدة أقسام أو المكتبة كلها؟
أجبرنا إعداد المصفوفة على استكمال المعلومات الناقصة قبل البدء، وساعد على تحديد مشروعات قليلة الكلفة عالية القيمة: بيانات نظيفة، وأطراف متحمسة لديها أسئلة، ونتائج تهم نطاقًا واسعًا من الموظفين. وكنا أقل حماسًا للمصادر التي لا يتضح المسؤول عنها أو لا يهتم أصحابها بالتحليل، أو تحتاج إلى تنظيف واسع وحلول التفافية، أو لا تهم نتائجها إلا عددًا قليلًا. ومع ذلك يمكن أن تبرر القيمة المرتفعة للنتيجة كلفة أعلى في أحد هذه الجوانب.
بنية البيانات والتخطيط:
لا يجعل جمع البيانات منها تلقائيًا أداة مناسبة للإجابة عن الأسئلة. فعندما يبدأ الجمع لمجرد الاعتقاد بضرورته، دون تحديد استخدامه، قد تغيب عناصر لازمة أو تختلف الصيغ أو يتعذر الربط بمصادر أخرى. وقد يحد ذلك من فائدة البيانات وإمكان تحليلها برمجيًا.
وقد تتغير ممارسات الجمع مع السنوات؛ ورغم أن تحسينها مرغوب، فإن تغيرها قد يصعب المقارنة عبر الزمن أو يجعلها مستحيلة. كذلك قد تخفي بيانات نظام المكتبة المتكامل (ILS) مشكلات: ينبغي التأكد من أن المعاملات المسجلة تقيس ما نريده فعلًا، مثل تمييز إعارات المستفيدين من الإعارات الناتجة عن العمليات الداخلية (Weyland, 2009).
وجدنا أن بعض الموظفين يصعب عليهم تصور الأسئلة التي تجيب عنها بيانات بعينها. وساعد عرض تقارير سابقة على توليد الأفكار، وكذلك اقتراح فئات عامة للأسئلة: هل تهمكم الاتجاهات عبر السنوات أو الفصول الدراسية أو الأيام أو الساعات؟ وأي خصائص للمستفيدين، مثل الانتماء الأكاديمي أو التخصص أو الموقع الجغرافي، قد تفسر استخدام الخدمة؟
أتاحت المحادثات للموظفين التقنيين فهمًا أوسع لاهتمامات المؤسسة وممارسات جمع البيانات، وأفادت الأقسام في أساليب الجمع والتنظيم وصياغة الأسئلة. ونأمل أن تؤدي هذه الخبرة إلى تخطيط مبكر يجعل قابلية التحليل وفائدته عاملين موجهين لجمع البيانات.
التخزين وإتاحة النتائج:
يؤثر مكان التخزين وطريقته في إمكان الوصول إلى البيانات والاستفادة منها، خاصة مع تعدد المشروعات. وبالنسبة إلى سجلات المعاملات المنتجة بالحاسوب، سواء كانت تقارير من نظام المكتبة أو سجلات لتطبيقات محلية، أنشأنا مجلدًا واحدًا على الخادم تتفرع منه مجلدات لكل مشروع. وأتاح ذلك بناء مجموعة من البيانات المنظمة، وإدارة صلاحياتها في مكان واحد، واكتشاف فرص لإعادة استخدامها.
اختلفت طريقة مشاركة النتائج بحسب طبيعة المشروع. ففي بعض الحالات قدمنا تقريرًا مكتوبًا ثابتًا، خصوصًا إذا احتاجت البيانات إلى تنظيف كبير أو تعذر مواصلة جمعها بسهولة، أو كان الهدف صورة آنية لخدمة معينة. وفي حالات أخرى كانت كلفة الجمع المستمر منخفضة وكانت متابعة الإحصاءات في أي وقت مفيدة؛ فكتبنا برامج بلغة (PHP) لمعالجة أحدث السجلات وعرض التقارير على الويب. وساعدت واجهة غوغل للتصور البياني (Google Visualization API) في إنشاء الرسوم المحدثة (Google, 2010).
عند تصميم السجلات المخصصة، وجدنا حقولًا مفصولة بعلامة الجدولة قابلة لإعادة الاستخدام. فالطابع الزمني لنظام يونكس (Unix timestamp) يسهل العمليات الحسابية والمقارنات الزمنية، وإضافة تاريخ ووقت مقروءين تسهل فحص السجل. وقد يفيد عنوان الإنترنت، لكنه يمكن استبعاده إذا كانت المعاملة تتضمن معلومات أكثر خصوصية، مثل كلمات الاستعلام. وتلي ذلك رموز تصنف نوع الفعل أو موقع الحاسوب أو الاستعلام أو غير ذلك. وقد وازنا بين البساطة والفائدة، وسهل التوحيد المحدود تطوير أدوات المعالجة. وهذا مثال لبنية سجل:
// Timestamp IP address Library Region code Computing platform Action
1250266660 152.1.107.147 VML 016 PC LOGIN
1250266663 152.1.222.47 HILL 003 MAC LOGOUT
قد تكبر السجلات بمرور الزمن وتستهلك الذاكرة إن عولجت دون انتباه. ووجدنا فائدة في قراءتها سطرًا بسطر ضمن حلقة، وإجراء الحسابات على السطور التي تحقق الشروط، والاحتفاظ بالقيم عند الحاجة فقط. ويوضح المقطع التالي طريقة القراءة وفصل الحقول:
if ($input_logfile) {
do {
$log_input_line = fgets($input_logfile);
list($timestamp, $ip_address, $library, $region_code, $platform,
$action) = explode("\t", $log_input_line);
// Do whatever you want with the data...
} while (!feof($input_logfile));
fclose($input_logfile);
} else {
print "Unable to open logfiles\n";
return;
}
ومن مزايا واجهة غوغل إمكان توليد شيفرة (JavaScript) بواسطة برنامج الخادم، باستخدام قيم محسوبة مباشرة من السجلات. وتبقى التقارير عندئذ مواكبة لأحدث البيانات. وأنشأنا مجلد ويب للتقارير المولدة برمجيًا، مع مجلد فرعي لكل خدمة أو تطبيق، لتسهيل الصلاحيات واكتشاف التقارير وإعادة استخدامها. والمثال الآتي يبين صيغة إدخال بيانات الرسم:
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("visualization", "1", {packages:["corechart"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var data = new google.visualization.DataTable();
data.addColumn("string", "Curriculum");
data.addColumn("number", "Total requests");
data.addRows(3);
data.setValue(0, 0, "English");
data.setValue(0, 1, 14269);
data.setValue(1, 0, "Adult & Higher Education");
data.setValue(1, 1, 11396);
data.setValue(2, 0, "Sociology");
data.setValue(2, 1, 6132);
var chart = new google.visualization.PieChart(document.getElementById("chart_div"));
chart.draw(data, {width: 600, height: 500, legend: "right"});
}
</script>
ويمكن توليد قيم البيانات من مصفوفة على النحو الآتي:
<?php
$i = 0;
foreach ($use_by_curriculum as $curriculum => $count) {
print "data.setValue($i, 0, '$curriculum');\n data.setValue($i, 1, $count);\n";
$i++;
}
?>
كما جمعنا الشيفرة التي تحدد الوحدات الزمنية الشائعة، مثل العام الأكاديمي وحدود الفصول، في ملف مشترك تستخدمه جميع البرامج. وبذلك تتحدث التقارير دون إعادة إعدادها يدويًا. ويعرض المقتطف التالي مثالًا لتصنيف تواريخ الفصل الربيعي لعام 2010، مع حذف الأسابيع الوسطى كما في المثال الأصلي:
// SPRING SEMESTER, 2010
if (($date >= "2010-01-11") && ($date <= "2010-05-16")) {
$semester = "spring";
$academic_year = "2009-2010";
if ($date >= "2010-01-11" && $date <= "2010-01-17") {
$week = 1;
// ... Intermediate weeks removed ...
} elseif ($date >= "2010-05-10" && $date <= "2010-05-16") {
$week = 18;
}
$semester_date_information = array(
'academic_year' => $academic_year,
'semester' => $semester,
'week' => $week
);
أمثلة من التحليل التعاوني:
تمثل المشروعات الآتية اتجاهًا متناميًا في مكتبات الجامعة نحو تعاون الموظفين التقنيين مع الأقسام، ولم ينفذ المؤلفان جميع هذه المشروعات بنفسيهما.
معاملات الخدمات المرجعية:
لا يتطلب التحليل دائمًا برمجة أو برامج متخصصة؛ الأساس تخطيط بنية البيانات والأسئلة وقدرتها على الإجابة. وتعاونّا مع قسم الخدمات المرجعية والمعلوماتية لدراسة الاتجاهات عبر الزمن والفصول والأيام، واتجاهات خدمة المحادثة، والاختلاف بين أنواع المعاملات ووسائطها، وعلاقتها بمؤشرات أخرى مثل الدخول إلى المكتبة واستخدام الحواسيب.
جُمعت معظم البيانات يدويًا في جداول (Microsoft Excel)، لذلك أجرينا التحليل والرسوم بالأداة نفسها؛ فقد كانت مألوفة وحققت الاحتياجات بقدر الأدوات الأكثر تعقيدًا. وساعدت النتائج على فهم ساعات الذروة وأسابيع الفصل الأكثر نشاطًا، وتغير أنواع الاستفسارات ووسائطها.
البحث الموحد:
أُطلقت أداة (QuickSearch) المحلية عام 2005 لربط المستفيد بالموارد والخدمات والأدوات (Sierra, 2007). وهي تشغل مربع البحث الرئيسي في الموقع وتجمع نتائج من قاعدة مقالات سَمّن (Summon)، وفهرس يعتمد (Endeca)، وصفحات المكتبة وعناوين الدوريات. ويديرها فريق مشترك من الخدمات البحثية والمعلوماتية ومبادرات المكتبة الرقمية.
قبل 2010، اعتمدت إحصاءات الأداة على برنامج تحليل الويب (Urchin). وفي يناير 2010 بدأ تسجيل مخصص يتضمن الوقت ونوع المعاملة: بحث أو نقرة؛ وإذا كانت نقرة سُجلت الوحدة الفرعية والرابط المختار. وأراد الفريق معرفة نسبة النقرات إلى عمليات البحث، والوحدات الأكثر اختيارًا، وتغير الاستخدام خلال الفصل، وأكثر كلمات البحث شيوعًا.
ساعدت التقارير على إعادة تصميم صفحة النتائج. فأُعطيت نتائج المقالات والفهرس مساحة أساسية متقاربة، لأن استخدامهما كان متقاربًا، بعدما كانت المقالات تستحوذ على مساحة أكبر. كما روقبت نسبة النقر إلى البحث للتحقق من أن التصميم الجديد لم يخفضها: بلغت 0.76 نقرة لكل بحث في الفصل السابق، ثم 0.88 في الأشهر الثلاثة الأولى من الفصل التالي. وساعد تقرير الكلمات الشائعة على اختبار جودة البحث بهذه الكلمات.
أدوات المقررات:
يولد تطبيق أدوات المقررات (Library Course Tools) عروضًا للموارد والأدوات موجهة إلى طلاب كل مقرر. وطُور عام 2008 بشراكة بين مبادرات المكتبة الرقمية والخدمات المرجعية والتعليمية (Casden et al., 2009). وشمل التعاون تحديد احتياجات البيانات وتنفيذ سجل مخصص، للإجابة عن تغير الاستخدام منذ الإطلاق وخلال الفصل، وأكثر التخصصات استخدامًا وأقلها، والمحتوى الأكثر فائدة في الوحدات المصغرة.
أمكن تحليل السجل على الخادم مباشرة واستخدام واجهة غوغل لعرض النتائج. وساعد التعاون المبكر بين التقنيين وغير التقنيين على إنشاء بنية قابلة للمعالجة البرمجية. وأظهرت النتائج أن الوحدات ذات المحتوى غير المتجدد أقل استخدامًا كثيرًا؛ فدفع ذلك إلى تطوير محتوى ديناميكي يركز على التخصصات.
كما ظهرت علاقة بين مشاركة أمناء المكتبات واستخدام الأداة. فارتفاع استخدام طلاب الهندسة الكيميائية مقارنة بحجم مجموعتهم يُفسر، على سبيل الفرضية، بحماس أمناء المكتبات المختصين وتواصلهم وإنتاجهم للمحتوى.
المجموعات الخاصة:
أنشأ مركز بحوث المجموعات الخاصة عام 2007 قاعدة (Microsoft Access) لتسجيل المستفيدين ونقل المواد واستخدامها. وعرف القسم قيمة البيانات، لكنه افتقر إلى الموارد التقنية لتحليلها بعمق. واكتشفنا المصدر من خلال التواصل مع الأقسام، ثم ناقشنا احتياجات القيّمين والموظفين والإدارة.
ولأن القاعدة محفوظة في نظام ملفات وليست على خادم ويب، أعددنا تقريرًا ثابتًا يغطي السنوات الثلاث المتاحة بدل تقرير حي. وحُللت الجداول المصدرة برمجيًا، واستُخدم (Adobe Illustrator) في إنشاء الرسوم. ومن النتائج المفيدة توزيع نسبة استخدام المواد المادية بحسب ساعات اليوم.
لكن بعض الأسئلة لم تجد بيانات كافية: لم تُسجل مجالات الاقتناء المرتبطة بكل مجموعة، فتعذر تحديد أكثرها استخدامًا بسهولة. وأمكن عد الإعارات، لكن تعذر تحليل الاستخدام بحسب المشروعات البحثية المستقلة، لأن جلسة البحث الممتدة أيامًا لم تُميز عن إعارات المواد الفردية.
وشملت مشكلات البنية عدم اتساق المفاتيح الأساسية بين الجداول، وغياب عدد قليل من السجلات، واستيراد بيانات قديمة دون تحويلها إلى الصيغة الحالية. وكانت هذه المشكلات قابلة للعلاج، لكنها أدت إلى استبعاد بعض البيانات من التحليل.
خاتمة:
قد يكون إطلاق برنامج واسع لتحليل البيانات صعبًا، لكن المبادرات التعاونية الصغيرة متاحة. ويستطيع أصحاب المهارات التقنية مساعدة الأقسام بالتفكير الحاسوبي. ورغم الوقت اللازم، خاصة حين لا يدخل التحليل والتواصل بين الأقسام في المهام المعتادة، فإن المكاسب قصيرة الأجل وطويلته كبيرة.
ساعدت التجربة أقسامًا متعددة على فهم استخدام تطبيقاتها وخدماتها. وكان بناء الشراكات بين الأقسام تحديًا ونتيجة إيجابية معًا. ونأمل أن تنمي هذه الجهود الوعي بممارسات جمع البيانات وفرص الاستفادة منها، وأن تدعم روح التعاون. كما تستمر فائدة السجلات المخصصة والتقارير الحية في التقييم الدوري. ونعمل مع زملائنا على ترسيخ جمع البيانات والتقييم ضمن التخطيط للخدمات والتطبيقات منذ البداية.
المراجع:
- Casden, J.; Duckett, K.; Sierra, T.; Ryan, J. (2009). Course Views: A Scalable Approach to Providing Course-Based Access to Library Resources. Code4Lib Journal, 6. Accessed December 6, 2010. http://journal.code4lib.org/articles/1218.
- Google. (2010). Google Visualization API. Accessed December 6, 2010. Interactive Charts.
- Sierra, T. (2007). A Single Search Box Interface to the NCSU Libraries, Two Years Later. Digital Library Federation Spring Forum, Pasadena, California, April 24, 2007. Accessed December 6, 2010. Presentation.
- Weyland, M. (2009). The Wise Use of Statistics in a Library-Oriented Environment. Code4Lib Journal, 6. Accessed December 6, 2010. http://journal.code4lib.org/articles/1275.
- Wing, J. (2006). Computational Thinking. Communications of the ACM, 49(3), 33–35.