لا تقم بالبناء والتكامل - دليل لتكامل CRM

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

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

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

هذا هو المكان الذي يكون فيه تكامل الطرف الثالث مفيدًا. لذا ، دعنا نتعمق ونرى ما إذا كان بإمكاننا تجنب بعض المزالق الشائعة.

تكامل CRM

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

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

قم بتضمين قسم التكنولوجيا الخاص بك في القرار

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

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

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

هل تحتاج إلى تكامل مخصص على الإطلاق؟

عندما يتعلق الأمر بالتكامل ، فليس من المستغرب وجود منصات موجودة بالفعل تعد بحل بعض المشكلات التي من المحتمل أن تواجهها. حاليًا ، يعد Zapier و IFTTT أكثر البرامج الواعدة.

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

وحتى إذا كان الأمر يتعلق بدمج البيانات المخصصة (الروبوتات المطلوبة وأسعارها) ، يمكن أن يعمل Zapier Webhooks كوسيط لتكاملك.

من ناحية أخرى ، إذا كنت تقوم بالفعل بإرسال البيانات إلى طرف ثالث ، فلماذا لا ترسلها مباشرة إلى نظام CRM؟ كلما زادت البيانات التي تريد مزامنتها ، كلما كان التكامل المباشر مفيدًا.

الذي ياخذني لنقطتي التالية.

هل تحتاج إلى مزامنة ثنائية الاتجاه؟

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

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

من المرجح أن يعني تغيير جهات الاتصال في نظام CRM أنك ستحتاج إلى تغيير تفاصيل الاتصال في نظام آخر ، أي أن التغييرات يجب أن تسير في كلا الاتجاهين.

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

كيف سيتم إخطارك بالتغييرات من CRM؟

إذا قررت إجراء مزامنة ثنائية الاتجاه ، فهناك سؤال متابعة: كيف تعرف أن شيئًا ما قد تغير من جانب CRM؟

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

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

في هذه الحالة ، سيستمر تغيير نظام الطلب الخاص بك وإنشاء البيانات عبر استدعاء API على نظام CRM. ولكن سيتم استطلاع جميع التغييرات من نظام CRM في فترة زمنية محددة.

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

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

مثال هنا هو HubSpot's CRM ، والذي يقدم webhooks بشكل عام ولكن ميزة webhook متاحة فقط في حزمة المؤسسة الخاصة بهم. ستقدم أدوات المحاسبة Zoho Books خمسة مهام سير عمل آلية (والتي تتضمن خطافات الويب) في أدنى مستوياتها.

هل بياناتك في حالة جيدة؟

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

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

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

قيود API

أخيرًا ، قيود واجهة برمجة التطبيقات (API) هي شيء يجب معالجته في أقرب وقت ممكن.

بافتراض وجود واجهة برمجة تطبيقات (وهو أمر ضروري في الأساس لأي تكامل) ، فمن المفيد النظر إلى قيود واجهة برمجة التطبيقات. يمكن لمعظم الشركات الناشئة التعامل مع حدود API الأساسية لمعظم أنظمة CRM. على سبيل المثال ، تقدم HubSpot 250000 استدعاء لواجهة برمجة التطبيقات لكل 24 ساعة حتى في مستواها المجاني. من ناحية أخرى ، فإنه يحد أيضًا من المكالمات إلى 10 في الثانية (100 إذا كنت تستخدم OAuth). تسمح شركة Salesforce الرائدة في السوق بـ 100،000 فقط كل 24 ساعة ولكنها تعرض شراء المزيد.

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

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

تنفيذ CRM

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

لا يزال هناك بعض من أفضل الممارسات التي يجب اتباعها خلال مرحلة التنفيذ.

جرب كل شيء في بيئة اختبار

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

هناك مشكلتان في هذا النهج:

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

   

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

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

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

تحديد المعرف لمطابقة الكيانات

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

بينما يبدو أنه من الرائع استخدام عنوان البريد الإلكتروني فقط (بعد كل شيء ، فهو معرّف شائع لسجل جهة اتصال) ، هناك حل أكثر عمومية - لكل سجل ، تقوم بالمزامنة مع نظام خارجي ومعرف في قاعدة البيانات الخاصة بك.

لذلك ، قم بتعديل جدول جهات الاتصال الخاص بك بعمود يسمى crm_id أو external_id . هذا النهج له ميزتان:

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

قبل:

بعد:

على سبيل المثال ، لنفترض أنك مطور Ruby on Rails يعمل على تطبيق يحتاج إلى مزامنة العملاء الحاليين والجدد مع HubSpot.

يمكن أن يبدو مثال التعليمات البرمجية المبسطة كما يلي:

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

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

عندما يتعلق الأمر برسم الخرائط ، اذهب بأسلوب حر

لقد رأيت مشاريع يُسبق التنفيذ فيها عن طريق إنشاء جدول بيانات Excel عملاق يحدد الأعمدة التي تذهب إلى حيث في نظام CRM ، مع شروح حول كيفية تحويل البيانات.

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

على الأقل بالنسبة لحقول الاتصال العامة (الاسم وعنوان البريد الإلكتروني ورقم الهاتف والعنوان) ، سيكون التعيين بسيطًا جدًا وعادة ما تكون التحويلات تافهة.

عندما يتعلق الأمر بتعيين الحالة للصفقات ، فإن المزيد من التواصل يكون مفيدًا (في بعض الأحيان ، يُطلق على الحالة الأولى اسم open ، وأحيانًا new ، وأحيانًا ، لا يتطابق نموذج الحالة مع 100٪ ، لذا سيتعين عليك تجميع الحالات معًا ). بدلاً من التوصل إلى الحل الأمثل ، انظر إلى بياناتك الحالية وشاهد كيف تتناسب بشكل أفضل مع نموذج بيانات CRM. بعد كل شيء ، أنت شركة رشيقة ، أليس كذلك؟

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

ضع في اعتبارك عمليات إعادة المحاولة

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

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

ما يعنيه هذا عمليًا هو - عندما تتصل بواجهة برمجة تطبيقات ، تأكد من إعادة محاولة مكالمتك في حالة حدوث مشكلة (رمز الحالة 500 من الجانب الآخر). يُعد تنفيذ عمليات إعادة المحاولة أمرًا يتم توفيره عادةً بواسطة مكتبات الجهات الخارجية للغتك التي تختارها.

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

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

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

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

تأكد من استخدام النظام بالفعل

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

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

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

تغليف

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

لذلك بالنسبة للمهندسين - حاول فهم احتياجات نظام خارجي مثل CRM أو نظام الفواتير عن طريق طرح أسئلة محددة مثل: كيف سيجعل هذا المنتج حياتك أسهل؟ هل فكرت في المنافسين؟ لماذا لا يعملون؟

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