مستأجر واحد، ومستأجرون متعددون، ومستأجرون مختلطون، ومستأجرون ضخمون، ومستأجرون مستأجرون، ومستأجرون مستأجرون،... إنه أمر مثير للسخرية ما هي المدة التي يذهب إليها بائعو البرامج عندما يريدون حقًا إرباك المشترين.
لقد قدمت الأسابيع القليلة الماضية بعض الضجيج المربك حقًا فيما يتعلق بمطالبات الإيجار المتعدد من بعض موردي تخطيط موارد المؤسسات (ERP).
يتضمن أحدث تطور أن أحد البائعين صرح بأن منتجه يمكن أن يكون متعدد المستأجرين إذا كان بإمكان بعض البائعين/شركاء الاستضافة تقديم تكوين قياسي لأكثر من عميل واحد. ما يحدث في هذا السيناريو هو أن بعض عملائهم سيشاركون نسخة واحدة من الكود أثناء ذلك قد تتواجد البيانات أو لا تتواجد معًا في قاعدة بيانات فعلية واحدة (سيكون ذلك منطقيًا بالطبع منفصل).
كل هذه المناورات في المصطلحات أصبحت مرهقة ومربكة للغاية للعملاء والمحللين. لذلك، دعونا نحصل على قطعة قماش وصابون وننظف هذا قليلاً. (بالمناسبة، هناك مكان لجميع خيارات البرامج هذه - ولكن لا يوجد سبب لجمعها معًا في مصطلح تقني واحد)
السيناريو 1
أعتقد (فقط رأيي المتواضع) ذلك متعدد الايجار يعمل مثل هذا: يقوم شخص ما ببناء ناطحة سحاب مذهلة. يحتوي على عشرات الطوابق حيث يمكن لكل مستأجر إجراء بعض التعديلات (على سبيل المثال، الخياطة) على مساحته لتناسب احتياجات أعماله (على سبيل المثال، أثاث المكاتب). يجب على هؤلاء المستأجرين مشاركة المناطق المشتركة (مثل الردهة والمصاعد وما إلى ذلك) ولكن لا يمكنهم تغييرها. ولا يمكنهم تغيير أي جوانب هيكلية للمبنى أيضًا. إذا قام مالك المبنى بإجراء تعديل على المبنى (على سبيل المثال، نظام تكييف الهواء)، فإنه يؤثر على جميع المستأجرين وجميع المستأجرين بالتساوي. قد يتم إجراء بعض التعديلات، مثل طلاء ردهات المصاعد، على مراحل وقد يحقق بعض المستأجرين بعض النجاح في تغيير الجدول الزمني لهذا العمل قليلاً. ومع ذلك، سيتم إنجاز العمل.
هذا هو نوع الإيجار المتعدد الذي يراه بعض المحللين على أنه تعدد إيجار حقيقي أو حقيقي. في البرامج متعددة المستأجرين، يتشارك جميع المستخدمين بشكل أساسي نسخة واحدة من التعليمات البرمجية. يمكنهم إجراء بعض التعديلات أو التخصيص للمنتج، لكنهم لا يستطيعون تغيير المنتج الأساسي بشكل أساسي. عند حدوث الترقيات، يحصل جميع المستخدمين عليها. قد يكون لدى المستخدمين رأي ما بشأن موعد حدوث الترقية بالضبط، ولكنها ستحدث بالتأكيد. يمكن للمورد إجراء هذه الترقيات بأقل جهد لأنه يحتاج فقط إلى ترقية نسخة واحدة من الكود. علاوة على ذلك، تحتوي هذه النسخة الواحدة على بنية تقنية واحدة فقط.
السيناريو رقم 2
باستخدام تشبيه آخر للبناء، عندما يقول المستأجر المحتمل لناطحة السحاب هذه أنه يحتاج إلى مصعد مخصص فقط لأنفسهم، رصيف الصنادل، وانحياز السكك الحديدية والرافعات العلوية، فهي ليست احتمالا جديا لمبنى مشترك. لا، إنهم بحاجة إلى منشأة "مصممة لتناسب" مثل مصنع لمرة واحدة.
في هذا السيناريو، يريد مشتري البرنامج ويحتاج إلى حل مستقل ومستأجر واحد. يمكن أن يكون هذا المنتج حلاً محليًا أو حلاً مستضافًا محليًا. وقد تحتوي على مجموعة تكنولوجية مختلفة (على سبيل المثال، RDBMS، وبرامج إدارة الأنظمة، وما إلى ذلك)، عن تلك المستخدمة في خط الإنتاج متعدد المستأجرين. باستخدام هذا الحل داخل الشركة، يكون للعميل الحرية في تعديل الكود واختيار عدم ترقية المنتج (إذا كانت هذه هي رغبته). يمكن تشغيل هذا الحل في مركز البيانات الخاص بالعميل أو على خدمة استضافة خاصة. ومع ذلك، نظرًا لأنه لن تتم ترقية الحل (تلقائيًا) بواسطة البائع وقد يحتوي على تعليمات برمجية غير قياسية، فهو حل مستأجر واحد. مستضاف أم لا، فهو مستأجر واحد.
السيناريو رقم 3
الآن، هذا هو المكان الذي يبدأ فيه الأصوليون والمسوقون في الالتقاء ببعضهم البعض. هناك سيناريو ثالث.
ومن الناحية العقارية، فإن هذا السيناريو يشبه منطقة صناعية. جميع السكان يتشاركون في نفس المرافق والطرق. يجب عليهم جميعًا تلبية نفس قيود تقسيم المناطق. جميع المرافق موجودة في منطقة عقارية مشتركة ولكن هذا أمر مشترك أو مشترك بقدر ما هو ممكن. يمكن لكل شركة تصميم منشأتها المخصصة لهذا الغرض وتحديد متى أو ما إذا كانت ترغب في الحفاظ عليها وفقًا لقيود تقسيم المناطق أو سندات الملكية. إذا أراد أحد مالكي العقارات ترقية نظام تكييف الهواء الخاص بهم، فيمكنهم ذلك ولن يؤثر ذلك على أي مالك عقار آخر. لا يزال هذا إيجارًا فرديًا مع بعض القيود. إذا أرادت شركتان العمل في موقع مشترك في منشأة واحدة في هذه المنطقة الصناعية، فيمكنهما ذلك؛ ومع ذلك، فإن أفعالهم منفصلة عن تصرفات شاغليها الآخرين. إن تسمية الشركتين الموجودتين في موقع مشترك باسم "متعددة المستأجرين" يعد أمرًا صادقًا ولكنه لا يمكن مقارنته حقًا بتعدد المستأجرين الموضح في السيناريو رقم 1.
بدأ بائعو البرامج في تقديم منتجاتهم بكل أنواع المرونة في هذا السيناريو الثالث. إنها تتيح للعملاء الاختيار بين مستأجر واحد مستضاف محليًا، وربما حل مستضاف متعدد المستأجرين (من نوع ما). أفضّل أن أسمي هذا "المستأجر المختلط' بدلاً من المستأجرين المتعددين. يفترض استدعاء آخر مستأجر متعدد أن العديد من العملاء سيوافقون طوعًا وبشكل دائم على الاستخدام نفس تكوين المنتج ويمكنهم الاتفاق على متى يريدون أن يكون المنتج كذلك، إن وجد ترقية. ولتوفير هذه المرونة، يعتمد الموردون بشكل متكرر على شركاء القنوات لاستضافة الحل وإجراء أي ترقيات يطلبها العميل وتحديد ما إذا كانوا يريدون تقديم الإصدار "متعدد/مختلط المستأجرين". ونتيجة لهذه الخيارات، يتوفر للعملاء خيار العودة إلى الحل داخل الشركة إذا أصبحت الخيارات المستضافة مرهقة.
كيف يصبح هذا مربكا
قامت إحدى المؤسسات الكبرى مؤخرًا بتقييم حلول إدارة علاقات العملاء (CRM). لقد تلقوا عددًا من المقترحات من شركاء التوزيع، كل منهم يعرض حلاً يقدمه بائع برمجيات. اشتمل اثنان من العطاءات على برنامج CRM من نفس البائع. قال أحد الشركاء إن الحل كان محليًا أو مستضافًا بينما قال الشريك الآخر إنه حل متعدد المستأجرين.
كان العميل في حيرة من أمره. لم يروا كيف يمكن لمنتج واحد أن يكون كل هذه الأشياء. لقد نظروا إلى موقع البائع الإلكتروني والضمانات ووجدوا أن اللغة مربكة في أحسن الأحوال. في النهاية، لم يتمكن العميل من معرفة الحقيقة: المنتج ورفض مقترحات شركاء القناة.
حديثاً
أعلن أحد الموردين الرئيسيين عن مفهوم المجمع الصناعي (السيناريو 3) لأحد خطوط إنتاجه. إنهم يسمحون شركاء القناة قرر ما إذا كانوا يريدون تقديم:
- حلول SaaS للمستأجر الواحد
- الإصدارات المحلية
- حل مختلط حيث سيتم استضافة جميع العملاء على جهاز واحد ولكن يمكن لبعض مجموعات العملاء اختيار قبول الإصدار الرأسي القياسي للمنتج. إذا وافقت هذه المجموعة الفرعية من العملاء على ذلك، فسيقوم شريك البائع (وليس البائع) بإجراء الترقيات في الأوقات المجدولة.
- خيار التنقل بين الإصدار المستضاف إلى الإصدار المحلي للمنتج.
في الرصاصتين الأخيرتين هناك بعض النقاط المهمة حقًا التي يجب التفكير فيها. أولاً، يجب على شريك القناة، وليس البائع، إجراء الترقيات والتصحيحات وما إلى ذلك. ثانيًا، سيتعين على العميل الدفع مقابل أنشطة الترقية هذه لأن البائع لن يوفرها. ثالثًا، يبدو خيار الانتقال من الاستضافة إلى داخل الشركة أمرًا لطيفًا ولكن نادرًا ما يتم تطبيقه عمليًا. لكي تعود الشركة إلى العمل المحلي، فإنها ستحتاج إلى ما يلي:
- أجهزة كمبيوتر جديدة أو إضافية
- تراخيص قاعدة البيانات الجديدة أو الموسعة
- تراخيص جديدة أو موسعة لأدوات إدارة الأنظمة
- تراخيص جديدة أو موسعة لإعداد التقارير والتحليلات وأدوات البيانات الأخرى
- إلخ.
إرشاد
ما يربك زملائي المحللين حقًا، وأظن أنه كذلك للعملاء المحتملين، هو إصرار مسوقي البرمجيات على تسمية كل شيء تقريبًا بـ "المستأجر المتعدد". إنهم يستخدمون مصطلحًا تقنيًا كحيلة تسويقية ويخلطون بينه وبين خيارات النشر.
في نهاية أحد هذه الإحاطات مع أحد كبار موردي تخطيط موارد المؤسسات (ERP)، قمت بتوضيح الأمر لهم بشكل صحيح: يرجى التحديد، قم بتسعير هذه المنتجات وتسميتها من خلال طرق النشر الخاصة بها بدلاً من تجميع كل خيار تحت خيار واحد مشوش شرط. على وجه التحديد، اقترحت أن يقوموا بالتسويق والعلامة التجارية بشكل منفصل:
- الحل على فرضية
- حل مستضاف لمستأجر واحد (مع تحديثات اختيارية لشريك القناة)
- حل مستضاف للمستأجرين المختلطين (مع تحديثات شريك القناة الاختيارية)
- حل سحابي حقيقي متعدد المستأجرين (مع التحديثات المقدمة من البائع)
يجب أن يكون لكل منها اسم خاص بها وسعرها وسياسات التحديث وأمن البيانات وبروتوكولات الوصول وما إلى ذلك. إن القيام بذلك يجعل من السهل على العملاء المحتملين فهم ما يشترونه وما لا يشترونه ولماذا. ولهذا السبب تمتلك هوندا علامات تجارية ونماذج ومستويات تجهيز منفصلة لجميع سياراتها. إذا أطلقوا على كل شيء اسم "اتفاق"، فلن يتمكن أي منا من تحديد ما يبيعونه أو يسعرونه أو يعرضونه وما إلى ذلك.
أرجو من البائعين تصويب هذا الأمر.