SharePoint

ماذا يحمل SharePoint، ولماذا يهمّ ذلك هنا

المشكلة في مستودعات الوثائق ليست غياب المحتوى بل تعذّر إيجاده. السياسة موجودة ومحدَّثة، وموقعها معروف لمن كتبها فقط.

وهذا يفسّر لماذا يُسأل زميل بدل البحث: البحث يعطي عشرين ملفاً، والزميل يعطي الجواب. والنتيجة أن المستودع يتحول إلى أرشيف لا مرجع.

وربطه يحوّله إلى مصدر إجابة: السؤال بلغة طبيعية، والجواب من الوثيقة الصحيحة، ضمن صلاحيات السائل نفسه لا خارجها.

• الوثائق — السياسات والإجراءات والنماذج.
• المواقع والمكتبات — النطاق يُحدَّد لكل مكتبة على حدة.
• الإصدارات — النسخة السارية لا المسودة.
• الصلاحيات — ما يحقّ للسائل رؤيته فقط.
• البيانات الوصفية — التصنيف والتواريخ حيث تكون مسجّلة.

النطاق والتحكم وما يبقى ملككم

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

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

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

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

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

ما الذي يحلّ محلّه هذا

ما يحلّ محلّه هذا هو البحث الذي لا يُجدي والسؤال الذي يُقاطع. الموظف الذي يحتاج سياسة يجرّب البحث مرة، ثم يسأل زميلاً، وهذا هو النمط الغالب.

والأثر مضاعف: وقت السائل، ووقت المسؤول، وخطر أن تكون الإجابة من ذاكرة زميل لا من الوثيقة السارية.

والخطر الأخير هو الأهم: السياسة التي تُنقل شفهياً تتحوّر. والاتصال يضمن أن الجواب من الوثيقة نفسها، بنسختها السارية.

كيف تُخرجون القيمة منه

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

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

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

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

حوكمة اتصال ستُسألون عنه

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

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

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

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

كيف يُنفَّذ هذا في أماكن أخرى، وأين يخفق

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

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

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

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