- «تاريخ العميل» في النظام القديم أربع طبقات: السجلات، والأنشطة والمراسلات، والمرفقات، وسجل التغييرات. لكل طبقة طريقة نقل وتكلفة مختلفة، فقرر لكل واحدة: نقل كامل، أو نقل ملخص، أو أرشيف يُرجع إليه.
- الحفاظ على التاريخ يعني أكثر من نقل السجلات: تاريخ الإنشاء الأصلي، ومن أنشأ السجل ومن يملكه ولو غادر المنشأة، وتواريخ دخول الفرصة كل مرحلة، والمعرّف في النظام القديم.
- اختبر الاستخراج من النظام القديم في الأسبوع الأول، فهو أكبر مخاطرة تقنية في المشروع، ولا تعرف حدوده إلا بالتجربة.
- التشغيل المتوازي بإدخال مزدوج نادرًا ما يفيد. الأنسب غالبًا: نافذة تجميد قصيرة، وترحيل نهائي بعد بروفة كاملة، ثم إبقاء النظام القديم للقراءة فقط مدة محددة قبل أرشفته.
حين تنتقل منشأة من نظام CRM قديم، فهي لا تنقل قائمة عملاء، بل سنوات من المتابعات والعروض والشكاوى والقرارات. تشرح هذه المقالة لمدير المشروع وفريق تقنية المعلومات كيف تحدد ما يُرحّل من هذا التاريخ وكيف، وما الذي يجب أن يبقى على حاله في كل سجل، وكيف تُدار فترة التحول من الاستخراج الأول حتى إيقاف النظام القديم.
ما الذي يعنيه «تاريخ العميل» في النظام القديم؟
السؤال «هل سننقل التاريخ؟» لا يُجاب بنعم أو لا، لأن التاريخ ليس شيئًا واحدًا. فكّكه إلى طبقات، وستجد أن لكل طبقة حجمًا وقيمة وصعوبة مختلفة:
| الطبقة | ما تشمله | من يحتاجها بعد التحول | ما يصعب فيها |
|---|---|---|---|
| السجلات | الشركات، وجهات الاتصال، والفرص المفتوحة والمغلقة، وعروض الأسعار، والعقود، والتذاكر | الجميع، يوميًا | تحويل المراحل والحالات بين النظامين، والعلاقات بين السجلات |
| الأنشطة والمراسلات | المكالمات، والاجتماعات، والمهام، والملاحظات، والرسائل البريدية المسجلة | المندوب وموظف الخدمة عند فتح ملف العميل | الحجم الكبير، وربط كل نشاط بسجله الصحيح، وتنسيق النصوص |
| المرفقات | العروض الموقعة، والعقود الممسوحة، والمراسلات الرسمية | المبيعات والمالية والشؤون القانونية | أدوات التصدير في بعض الأنظمة لا تشملها، أو تصدّرها دون ربط بسجلاتها |
| سجل التغييرات | من غيّر أي حقل ومتى، وتنقل الفرصة بين المراحل | الإدارة والتدقيق، وتقارير مدة دورة البيع | غالبًا لا يُستورد إلى سجل التدقيق في النظام الجديد، لأن ذلك السجل يوثق ما يحدث فيه هو فقط |
الطبقة الرابعة تستحق وقفة. سجل التدقيق في النظام الجديد يوثق العمليات التي تجري فيه منذ تشغيله، ولا يصح أن يُحشى بأحداث مستوردة تبدو كأنها وقعت فيه. لذلك يُنقل سجل التغييرات القديم، إن احتيج إليه، إلى مكان مستقل: كائن تاريخي للقراءة فقط مرتبط بالسجل، أو أرشيف قابل للبحث. والاستثناء المهم هو تواريخ مراحل الفرص: متى دخلت الفرصة كل مرحلة. هذه تحتاجها تقارير مدة البيع ومعدلات التحول، فتُستخرج وتُنقل حقولًا في الفرصة نفسها أو سجلات مرحلية مرتبطة بها.
لكل طبقة قرار: نقل كامل أم ملخص أم أرشيف؟
نقل كل شيء يبدو الخيار الأسلم، لكنه يطيل المشروع ويرفع تكلفته، وقد يملأ النظام الجديد بما لا يفتحه أحد. وترك كل شيء في الأرشيف يعني أن المندوب سيفتح نظامين ليعرف قصة عميل واحد. القرار الأوسط يُتخذ لكل طبقة بثلاثة أسئلة: هل تحتاجها الأعمال اليومية؟ هل تبني عليها تقارير؟ هل تلزم المنشأة بالاحتفاظ بها لسبب نظامي أو تعاقدي؟
مثال توضيحي| البيانات | القرار | السبب |
|---|---|---|
| كل الشركات وجهات الاتصال النشطة | نقل كامل | أساس العمل اليومي |
| الفرص المغلقة في آخر ثلاث سنوات | نقل كامل مع تواريخ المراحل | تقارير الربح والخسارة ومدة البيع، وتاريخ العلاقة عند التفاوض |
| الفرص الأقدم | ملخص في ملف العميل | عدد الصفقات وقيمتها وتاريخ آخرها يكفي لفهم العلاقة |
| الأنشطة في آخر سنتين | نقل كامل | المندوب يحتاج آخر ما دار مع العميل |
| الأنشطة الأقدم وسجل التغييرات | أرشيف قابل للبحث | يُرجع إليه عند الحاجة، ولا يُثقل الملف اليومي |
| مرفقات العقود والعروض الموقعة | نقل كامل | مستندات ملزمة يُرجع إليها عند التجديد والنزاع |
المدد في الجدول مثال، وتحددها كل منشأة بطول دورة بيعها وطبيعة عقودها. المهم أن يُكتب القرار ويعتمده صاحب البيانات، وأن يعرف المستخدمون أين يجدون ما لم يُنقل. وسياسة الاحتفاظ نفسها، أي كم يبقى الأرشيف ومتى يُحذف، قرار حوكمة مستقل تناقشه مقالة سياسات الاحتفاظ والتصدير والحذف في CRM.
ما يجب أن يبقى على حاله في كل سجل
نقل السجل لا يعني نقل قيمه الظاهرة فقط. هذه التفاصيل تضيع بسهولة، وضياعها يفسد التقارير التاريخية دون أن يلاحظه أحد في الأسابيع الأولى:
- تاريخ الإنشاء الأصلي: إن أخذت كل السجلات تاريخ يوم الترحيل، ظهرت كل الشركات عملاء جددًا في شهر واحد، وتعطلت تقارير عمر العلاقة. يُنقل التاريخ الأصلي إلى الحقل المخصص له إن سمح النظام بتعبئته عند الاستيراد، أو إلى حقل «تاريخ الإنشاء في النظام السابق».
- المالك ومن أنشأ السجل: الموظفون الذين غادروا تبقى أسماؤهم جزءًا من التاريخ. لا تُنسب أنشطتهم إلى من ورث عملاءهم، بل تُحفظ باسمهم عبر مستخدمين غير نشطين أو حقل «المنفذ الأصلي». أما ملكية العميل الحالية فتُسند إلى موظف قائم.
- المعرّف في النظام القديم: يُحفظ في كل سجل منقول. به تُربط السجلات ببعضها أثناء الترحيل، ويُستورد الفرق دون تكرار، ويُعثر على الأصل عند أي سؤال لاحق.
- المنطقة الزمنية: بعض الأنظمة تصدّر الأوقات بالتوقيت العالمي المنسق، فإن استوردت على أنها بتوقيت الرياض ظهرت مواعيد الاجتماعات وأوقات المكالمات أبكر من وقتها الفعلي بثلاث ساعات: اجتماع الساعة العاشرة صباحًا يظهر في السابعة. افحص عينة من المواعيد قبل أي ترحيل كامل.
- قيم المراحل والحالات: جدول تحويل مكتوب من قيم النظام القديم إلى قيم الجديد. والقيمة القديمة التي لا مقابل لها لا تُسقط، بل يُتخذ فيها قرار.
والتعامل مع السجلات المكررة المتراكمة في النظام القديم جزء من هذا الترحيل، لكنه منهجية مستقلة بقواعدها ومراجعتها البشرية، تشرحها مقالة دمج سجلات العملاء المكررة أثناء الترحيل. أما إن كانت بعض البيانات خارج النظام القديم أصلًا، في ملفات Excel لدى الفروع، فيُضاف مصدرها بالطريقة الموضحة في مقالة نقل بيانات Excel إلى CRM مع الحفاظ على العلاقات.
الاستخراج: أكبر مخاطرة تقنية، فاختبره أولًا
كثير من المشاريع تكتشف في منتصفها أن النظام القديم لا يصدّر المرفقات إلا يدويًا واحدًا واحدًا، أو أن واجهته البرمجية تحدّ عدد الطلبات فيحتاج الاستخراج الكامل أيامًا، أو أن الاشتراك انتهى قبل اكتمال التصدير. لذلك يكون أول مخرج تقني في المشروع استخراجًا تجريبيًا كاملًا لعينة من كل طبقة، لا تصميم الشاشات.
وقبله، اجمع إجابات هذه الأسئلة من فريقك أو من مورد النظام القديم:
- ما طرق التصدير المتاحة؟
أداة تصدير من الواجهة، أو واجهة برمجية، أو نسخة من قاعدة البيانات إن كان النظام على خوادمكم. ولكل طريقة ما تشمله وما تستثنيه.
تقنية المعلومات - هل يشمل التصدير المرفقات وسجل التغييرات والحقول المخصصة؟
كثيرًا ما تُصدر السجلات الأساسية بسهولة، وتبقى هذه الثلاثة خارج التصدير الافتراضي.
تقنية المعلومات مع المورد القديم - ما حدود الاستخراج؟
عدد الطلبات المسموح في الواجهة البرمجية، وحجم الملف الواحد، والمدة المتوقعة للاستخراج الكامل. هذه تحدد هل يتسع التجميد لاستخراج كامل أم يلزم ترحيل الفرق.
تقنية المعلومات - ماذا ينص العقد عن تسليم البيانات؟
الصيغة، والمدة، وأي رسوم، وتاريخ انتهاء الاشتراك الذي يجب أن يسبقه كل شيء بهامش كافٍ.
المشتريات والشؤون القانونية
تنبيه: لا تُنهِ اشتراك النظام القديم أو ترخيصه قبل اعتماد الترحيل النهائي وتسلّم الأرشيف كاملًا والتحقق من فتحه. تاريخ انتهاء العقد القديم قيد على الجدول الزمني كله، فاعرفه في أسبوع المشروع الأول.
الجدول الزمني لفترة التحول
تتكرر في مشاريع الانتقال مراحل ثابتة، وإن اختلفت مددها بحجم البيانات وعدد الطبقات المنقولة. المخطط التالي مثال لمشروع متوسط، يوضح تداخل المراحل وموقع التجميد والإطلاق:
- الجرد وخريطة الحقول وقرارات النطاق1–2
- الاستخراج التجريبي لكل طبقة2–3
- الترحيل التجريبي الأول ومراجعتهالأسابيع 3–5
- الترحيل التجريبي الثاني واختبارات القبول عليه6–7
- بروفة التحول الكاملة بالتوقيت الفعلي (الأسبوع 8)8
- التجميد والترحيل النهائي والإطلاق (الأسبوع 9)9
- الدعم المكثف والنظام القديم للقراءة فقطالأسابيع 9–12
- أرشفة النظام القديم وإيقافه (الأسبوع 12)12
لاحظ أن اختبارات القبول تجري على بيانات مرحّلة، لا على بيانات تجريبية مصطنعة. فالمستخدم الرئيسي حين يفتح ملف عميل يعرفه، يكتشف في دقائق ما لا تكشفه تقارير الأعداد: نشاط مربوط بفرصة غير فرصتها، أو عقد بلا مرفقه. تصميم هذه الاختبارات وسيناريوهاتها موضوع مقالة اختبارات قبول CRM قبل الإطلاق.
التشغيل المتوازي: ثلاثة خيارات ومتى يناسب كل منها
يُقترح التشغيل المتوازي عادة بوصفه ضمانًا: يعمل الفريق على النظامين معًا لفترة، فإن تعثر الجديد بقي القديم. لكن «التوازي» يحمل معاني مختلفة، ولكل منها ثمن:
| الخيار | كيف يعمل | متى يناسب | ثمنه |
|---|---|---|---|
| إدخال مزدوج | كل عملية تُسجل في النظامين | حين توجد حسابات حرجة يلزم التحقق من تطابقها، كالعمولات أو الفوترة، ولمدة قصيرة جدًا | ضعف العمل على الفريق، وتباعد البيانات بين النظامين خلال أيام، وتأخر التبني |
| القديم للقراءة فقط | العمل كله على الجديد، والقديم مرجع للاطلاع | أغلب المشاريع، خاصة مع نقل جزئي للتاريخ الأقدم | ترخيص أو تشغيل النظام القديم مدة إضافية |
| انتقال على موجات | فريق أو فرع ينتقل، والباقون على القديم حتى موجتهم | منشآت كبيرة متعددة الإدارات أو الفروع | ترحيل متكرر، وقواعد لمن يملك العميل المشترك بين موجتين |
الإدخال المزدوج الكامل يبدو أكثر أمانًا، لكنه في الغالب يضعف الأمان نفسه: بعد أيام قليلة يُحدَّث أحد النظامين ويُنسى الآخر، فلا يعود أي منهما مرجعًا موثوقًا. والانتقال على موجات قرار تنظيمي أوسع من الترحيل، يتناول ترتيبه واعتمادياته مقال خطة تطبيق CRM على مراحل للشركات متعددة الإدارات.
نافذة التجميد والتحول النهائي
التجميد هو الفترة التي يتوقف فيها التعديل على النظام القديم حتى ينتهي الترحيل النهائي. كلما قصرت قلّ تعطل العمل، لكنها يجب أن تتسع للاستخراج والتحميل والتحقق وقرار الإطلاق. وفي السعودية تُختار عادة نهاية الأسبوع، فيبدأ التجميد مساء الخميس ويُفتح النظام الجديد صباح الأحد.
مثال توضيحيإعلان التجميد، وتحويل صلاحيات النظام القديم إلى القراءة فقط لكل المستخدمين.
الاستخراج النهائي. إن كان الاستخراج الكامل أطول من النافذة، يُستخرج الفرق فقط: السجلات المعدلة منذ آخر ترحيل تجريبي بحسب حقل «تاريخ آخر تعديل».
التحميل إلى النظام الجديد بالترتيب نفسه الذي نجح في البروفة، ثم تقرير المطابقة بالأعداد والمجاميع.
فحص سريع من المستخدمين الرئيسيين: كل منهم يفتح عشرة عملاء يعرفهم ويراجع ملفاتهم.
اجتماع قرار الإطلاق أو التراجع، بمعايير مكتوبة سلفًا.
بدء العمل على النظام الجديد، مع دعم مكثف في الموقع أو عن بعد.
أهم ما في هذه الخطة أمران. الأول: معايير قرار الإطلاق مكتوبة قبل التجميد، مثل تطابق الأعداد لكل نوع سجل، وعدم وجود سجلات يتيمة، ونجاح فحوص المستخدمين الرئيسيين دون ملاحظة تمنع العمل. الثاني: خطة التراجع. إن كان القرار عدم الإطلاق، يُعاد فتح النظام القديم للتعديل صباح الأحد، ولم يخسر أحد شيئًا سوى عطلة نهاية الأسبوع. وجود هذا الخيار هو ما يجعل القرار موضوعيًا لا تحت ضغط.
وحقل «تاريخ آخر تعديل» في النظام القديم يستحق اختبارًا مسبقًا: في بعض الأنظمة لا يتغير عند إضافة نشاط أو مرفق إلى السجل، فيفوت ترحيلَ الفرق ما أضيف في الأيام الأخيرة. اختبره في البروفة بتعديلات معروفة تتحقق من وصولها.
كيف تتحقق من أن التاريخ لم يضع؟
تقرير الأعداد يثبت أن السجلات وصلت، لكنه لا يثبت أن تاريخها سليم. أضف فحوصًا موجهة للتاريخ تحديدًا:
- إعادة إنتاج تقرير قديم: اختر تقريرًا معروفًا من النظام القديم، مثل الصفقات المكسوبة لكل مندوب في السنة الماضية، وأنتجه من النظام الجديد. يجب أن يتطابق العدد والقيمة. الاختلاف يكشف مشكلة في المالكين أو تواريخ الإغلاق أو تحويل المراحل.
- الخط الزمني لعينة عملاء: عشرون عميلًا بتاريخ طويل، يُقارن خطهم الزمني في النظامين جنبًا إلى جنب: عدد الأنشطة وتواريخها وترتيبها.
- المرفقات: فتح عينة من المرفقات فعليًا، لا التحقق من وجود أسمائها فقط. والتأكد من أن العربية في أسماء الملفات لم تتحول رموزًا.
- الأوقات: مقارنة وقت عشرة اجتماعات في النظامين للتأكد من عدم الانزياح الزمني.
- تواريخ المراحل: تقرير مدة البقاء في كل مرحلة لعينة فرص مغلقة، مقارنة بما يعرفه مدير المبيعات عن تلك الصفقات.
قبل أن تحدد موعد الإطلاق
ما سبق يعني أن موعد الإطلاق لا يُحدد قبل معرفة أمرين: ما يمكن استخراجه فعلًا من النظام القديم وبأي سرعة، وقرارات النطاق لكل طبقة من التاريخ. والتعرف عليهما يحتاج أسابيع قليلة في بداية المشروع، ويوفر أشهرًا من التأخير لاحقًا. وتصف صفحة الترحيل من نظام سابق الإطار العام لخطة الترحيل وتقرير المطابقة، وصفحة مراحل التنفيذ ومخرجاتها موقع الترحيل من المشروع كله.
وإن كنتم تخططون للانتقال من نظام قائم، فشاركونا اسم النظام الحالي وطرق التصدير المتاحة فيه وحجم البيانات التقريبي وتاريخ انتهاء اشتراكه، عبر طلب تقييم نقل البيانات. نراجع معكم ما يمكن نقله من كل طبقة وبأي طريقة، ونقترح جدول تحول يتسع للتجارب والبروفة قبل موعد انتهاء العقد القديم.
أسئلة شائعة
لا تُنقل تقنيًا، لأن كل نظام يبنيها بطريقته. لكنها تُجرد وتُوثق في بداية المشروع، ثم يُعاد بناء ما زالت الحاجة إليه قائمة. وهذه فرصة لحذف القواعد التي لم يعد أحد يعرف سبب وجودها، ولتبسيط التقارير المتراكمة.
غالبًا لا. الرسائل أكبر طبقة حجمًا وأقلها رجوعًا إليها بعد مرور وقت. يكفي عادة نقل رسائل فترة حديثة مرتبطة بالعملاء والفرص النشطة، وأرشفة الباقي في مكان قابل للبحث. ويُحدد الحد الزمني بطول دورة البيع وطبيعة المراسلات في المنشأة.
بقدر ما يكفي لتأكد المستخدمين من أنهم لا يحتاجون إليه، وهو غالبًا أسابيع لا أشهر. راقب عدد مرات فتحه: حين يقترب من الصفر لبضعة أسابيع، يُصدَّر أرشيفه النهائي ويُتحقق من فتحه ثم يُوقف. إبقاؤه طويلًا يغري بالعودة إليه، ويؤخر اعتماد الفريق على النظام الجديد.
صاحب البيانات في المنشأة، لا فريق التنفيذ وحده. يعرض فريق التنفيذ تقرير المطابقة ونتائج الفحوص، ويعتمد مسؤول المشروع في المنشأة ومدير الإدارة الأكثر اعتمادًا على البيانات. ويُحفظ الاعتماد مع التقرير في وثائق المشروع.