Качество партнеров, рынок, проекты

[Pavel]

Цитата:

Сообщение от George Nordic

Что-то мы совсем клиентов упустили из виду.

Начнем с экосистемы. Я так подразумеваю, что имеется в виду партнерская экосистема. В ней 3 основных составляющих: продукт, производитель продукта (вендор) и непосредственно клиент.

Экосистема формируется в первую очередь вокруг продукта (который, в свою очередь, должен удовлетворять запросам клиентов), когда партнерам есть что внедрять (мы говорим про "проектные" продукты). Если продукт переходит другому вендору, то экосистема просто переходит к другому вендору, принимая новые "правила игры" или покидая канал. Как мы помним, партнерская сеть Дамгард / Навижн / субы CITP плавно перетекли в MBS, плюс на рынке стали появляться новые небольшие партнеры, т.к. MBS лишил эксклюзива на территорию крупного партнера. Но! Я не помню, что бы "классические" партнеры сказали "О! А что это еще в прайс-листе появилось? Давай и это продавать будем!". Вернее, сказать-то может и сказали, но просто так "взять и продать" продукты, требующие внедрения, почему-то не получилось. Таким образом вокруг 3х продуктов, предлагаемых MBS на рынке, выстроилась партнерская экосистема, причем каждый партнер специализировался в основном на одном, максимум - 2 продуктах. Да, были трения, но в целом партнерам было чем заниматься - был продукт и пул клиентов, которым его можно было предложить, и которым он подходил. Тем более что появился опыт, "решения" - причем неплохие, и партнеры приходили не с голой платформой, а с кучей допиленного функционала. Если сильно изменить продукт, то все данные доработки будут бесполезны - это раз. Два - клиенты тоже изменились. И они хотят видеть продукт или "решение", которое лучше подходит именно к их бизнесу. Но вендор НИКОГДА не сделает "универсальный" продукт, который подходит каждому клиенту - это удел партнеров. Т.к. вендор обычно не работает с клиентами напрямую, у него должна быть отлично выстроена обратная связь - на что жалуются партнеры, что именно нужно основной массе заказчиков, чего из основных вещей (а не хотелок одного капризного клиента) не хватает в системе, и вести разработку в данном направлении, покрывая платформой основные общие механизмы и позволяя партнерам делать уже более узконаправленные решения. Максимум, что он может сделать - это принудительно продавать удачные отраслевые решения партнеров по всему каналу, включая их в свой прайс-лист, позволяя прочим партнерам быстрее внедрять вертикальные (ТОРО, ритейл) и горизонтальные (например, расширенное бюджетирование или кадры) решения, и делая внедрение более быстрым и маржинальным. Клиенту не нужен ни Х++, ни морфикс, ни слои - им на это, в общем-то, все равно. Им нужен продукт, который закроет их потребности, будет удобным и шустро работать, при этом - легко изменяемый под именно их потребности.

С Уважением,
Георгий

Мысль в целом наверная интересная и во многом правильная, но... есть, как говорится - 'но'. Можно подискутировать.

Точнее, до слов - 'вендор НИКОГДА...' все вроде как, исторически и фактологически соответствует и по сути, наверное, оно так и было. А вот дальше, видимо, начинается дифференс, между CITP, Navision, MBS... и вендорами 'вообще'.
Со своего опыта (руководство отделом разработок и партнерским отделом в Columbus, потом внутри SAP и его экосистемы, некоторого общения с российским и международным руководством MBS) вижу следующую 'разницу'. В SAP отраслевое решение ведет вендор, отвечает за его поддержку перед 'ключевыми в отрасли клиентами', внутреннюю поддержку перед подразделениями корпорации (продавцами, консультантами, службой поддержки, отраслевыми партнерами), собирает требования и планирует разработку новой версии, предоставляет бета-версию ключевым заказчикам для тестирования реализации их требований и доработки 'детских болезней' до выхода на рынок 'оффициального релиза'. Потом передает знания через соответствующие подразделения корпорации партнерам внедряющим отраслевые решения и заказчикам их использующим.
Сейл, который будет продавать отраслевое решение, обязательно будет иметь опыт работы в отрасли, при нем будет солюшн инженер, который знает продукт, в проекте может участвовать партнер, имеющий опыт внедрений данного отраслевого решения, а вендор может по требованию заказчика сделать QA проекта.
Ну, и дальше следующий lifecycle... к следующей версии или новой технологии.
А ты говоришь 'никогда'!