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

[Ivanhoe]

Недавно была, на мой взгляд, достаточно трезвая статья про рынок внедрений 1С:
http://www.cnews.ru/articles/2017-05...takim_podhodom

Хотелось бы услышать мнение сообщества именно про проблему рынка / запросов клиентов / партнеров. Если не думать именно про ПО, а про эко-систему. Может, в чем-то рынок AX был похож в начале / середине 2000-х?

[pitersky]

Статья хорошая
Но до сути проблемы авторы кмк так и не докопались. Хотя подошли к ней очень близко

[Ivanhoe]

А в чем суть по вашему?

[George Nordic]

Описывал в своем журнале. Здесь - даже на знаю, могу перепостить, наверное... Если интересно.

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

[Ivanhoe]

У меня, например, ссылка закрыта на доступ.

[George Nordic]

Цитата:

Сообщение от Ivanhoe

У меня, например, ссылка закрыта на доступ.

Вообще на LiveJournal? Или к этой записи?

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

[George Nordic]

Мы уже говорили о том, как умирают компании. Поговорим о том, как они возникают. Да, опять - я говорю про "проектные программные продукты" - ни про железо, ни про гаджеты, ни про игрушки - я на них не специализируюсь. Каждая компания имеет свой пусть развития. И он очень похож у разных компаний, занимающимся схожим видом бизнеса. Итак, можно выделить следующие стадии, прям по Hype Cycle:

1. "Стартап". Обычно - под уже готового заказчика. Т.е. небольшая команда людей делает продукт для одного заказчика, потом видит что "это хорошо" и "отпочковывается" - уходит в свободное плавание.
2. "Всё сами". Команда идет по рынку, сначала по похожим компаниям. Начинают распределяться роли внутри компании - у кого-то лучше получается разрабатывать продукт, у кого-то внедрять, у кого-то - продавать. Возникает компания, которая создает продукт - вендор.
Самый критический момент, между прочим ,90% компаний прекращают свое существование именно на данной стадии. Ну, не получилось продать, не пошел продукт, нет денег на развитие.
3. "Первые партнеры". Если все получается и продукт востребован, то вал заказов превышает способность небольшой компании реализовать все проекты. Однако, положение еще нестабильное, что мешает резко набрать персонал. Выход, по которому идет большинство компаний - это становление партнерской сети. Иногда кто-то из головной компании (у кого получалось внедрять) уходит и создает партнера.
4. "Эксклюзивные партнеры". Продавать и внедрять новый продукт - это большой риск. Поэтому новые партнеры хотят застолбить за собой рынок и получить огромную маржу, которая покрывает их риски. Это время эксклюзивов и огромной партнерской маржи. Вендор легко дает подобные условия, партнеры для них в этом случае - это шанс увеличить распространение продукта и завоевать рынок.
5. "Рост партнерской сети". Если продукт начинает успешное шествие по рынку, то все больше людей и компаний желает им заниматься. Особенно видя, какие хорошие условия получают первые партнеры, которые вовремя рискнули и начали заниматься данным продуктом. И, при этом, они готовы на гораздо более скромные условия. Начинается найм новых партнеров. На этом этапе появляются первые правила и партнерские программы. Клиенты - в основном средний бизнес.
6. "Содом". Клиентов все больше, и вот уже стали попадаться первые большие заказчики и крупные проекты. Старые партнеры высказывают недовольство, что выходят новички. У них возникает конкуренция, падает маржа. Да и вендор уже не так благостно смотрит на тех, кто помогал ему расти, и обещанная когда-то маржа сейчас кажется очень уж большой. Еще бы, когда есть новые партнеры, довольные и половиной от подобных условий. Новые - тоже недовольны - у ни пошли первые продажи, при этом старые партнеры стремятся задушить их бизнес, воруя их заказчиков, предлагая им более выгодные условия и давя "опытом". Плюс - старые партнеры начинают шантаж вендора, типа, займутся конкурирующим продуктом и тому подобное. Как ни странно, на этом этапе происходит самая важная вещь - определение дальнейшей работы и стратегии развития. Часто "старые" партнеры прогибают вендора, что ведет к ограничению числа новых партнеров. Им становится неинтересно заниматься продуктом, где их не поддержат, и они ищут новые пути развития и продукты. Старые сидят на своих заказчиках, "новая кровь", которая могла бы прийти он новых партнеров, не приходит. Число партнеров падает, и вместо сотен остаются десятки, а то и единицы. Новых заказчиков почти нет, и система потихоньку теряет рынок. Но есть и другой путь:
7. "Стабилизация канала". Очень сложный. Характеризуется активной работой с партнерской сетью. Необходимо быть сверх-гибким и принимать множество соломоновых решений, угождая и старым партнерам, и новым. Плюс, возникают партнеры "классического типа" - перепродавцы железа или коробок, которые хотят получить свой кусок пирога, блокируя доступ к своим заказчикам. Однако, они не понимают и не умеют продавать проекты. При этом могут порушить канал, отбивая у "консалтинговых" партнеров продажу лицензий. Обычно - это самый длинный этап жизни компании, и множество событий происходит в течении этого периода - выходят и меняются правила партнерской программы, развивается обучение партнеров, вводится дифференциация по вертикалям и специализации, вводятся требования по сертификации и, конечно, вводится:
8. "Вендорский контроль". С какого-то этапа становится понятно, что даже самый расчудесный партнер не может обладать полным пониманием всех нюансов продукта. Хотя, конечно, отраслевая экспертиза у партнеров в целом гораздо выше, чем у вендора. Обычно это осознание происходит, когда крупных заказчиков все больше и больше, и они предъявляют жесткие требования к экспертизе партнеров. "Завалить" подобный проект - все еще смерти подобно, хотя уже и не так критично, как на предыдущих стадиях. Но компания на данном этапе стремится к крупным заказчикам и огромным проектам, и им очень важно показать, что они умеют работать с и enterprise сегментом. Поэтому тут уже вендор больше переживает, справится ли партнер. Да и сами клиенты требуют Вендорского надзора и Quality Assurance. На самом деле, правильно подозревая, что у вендора больше возможностей что-то быстро исправить, если проблема касается самого продукта. Вендор начинает развивать свой консалтинг, вызывая недовольство не только старых, но и новых партнеров, которые опасаются конкуренции теперь уже и со стороны вендора. И снова - новые правила, гибкость, соломоновы решения...
9. "Все сначала". В какой-то момент компании приходится что-то менять. И не всегда перемены к лучшему. К этому моменту компании 15-25 лет, и отцы-основатели уже почивают на лаврах успеха. Лучшее, что может случиться - это новый рынок и/или новый продукт, который запустит всю вереницу заново...

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

[Bobkov]

Цитата:

Сообщение от Ivanhoe

Хотелось бы услышать мнение сообщества именно про проблему рынка / запросов клиентов / партнеров.

Я тоже на похожую тему статью писал когда-то: http://www.ippnou.ru/article.php?idarticle=007187 (заголовок и аннотация - редакции).
А причина в том, что у заказчиков не хватает управленческих компетенций. Главное, по определению требований к проекту внедрения.

[ax_mct]

Цитата:

Сообщение от Ivanhoe

Хотелось бы услышать мнение сообщества именно про проблему рынка / запросов клиентов / партнеров. Если не думать именно про ПО, а про эко-систему. Может, в чем-то рынок AX был похож в начале / середине 2000-х?

Проблема рынка в популярности.
Проблема AX/ AX7 в недостаточной популярности, из-за этого и короткое одеяло -- голову (вендора) накрыл - ноги (партнеры) мерзнут.
Проблема 1С в излишней популярности, из-за этого одеяло растянуто и тонко - мерзнут все.

Есть мнение что основой эко-системы является платформа которая в два часа ночи кажется самым естественным выбором для воплощения идеи. То есть популярность не среди тех кто продает и покупает, а среди тех кто создает. Как основа здоровой эко-системы.
Но это увод темы в сторону от взаимоотношений участников к платформе.

http://www.eaconsult.com/2016/11/28/...-sap-stack-up/
The Ecosystem/Platform War: How do Microsoft, Salesforce.com, and SAP Stack Up?

[pitersky]

Цитата:

Сообщение от Ivanhoe

А в чем суть по вашему?

Если вкратце - то проблема в том, что предприятия, внедряющие ERP-системы, не особо нуждаются во внедрении для ведения своего бизнеса, это просто дорогая и модная игрушка. Отсюда сразу вытекают все описанные проблемы - и нечеткость изначальной постановки, и невысокий интерес топ-менеджмента, и сопротивление рядовых сотрудников. И принцип лимона отсюда же - у всех примерно одинаковый список формально успешных внедрений. Соответственно, еще одно формально успешное внедрение проще всего сделать через вендора, предлагающего минимальную цену.

[mazzy]

Цитата:

Сообщение от pitersky

предприятия ... не особо нуждаются во внедрении

предприятие не может нуждаться или не нуждаться.
предприятие - это коллектив
нуждаются или не нуждаются во внедрении отдельные люди.

дальше стоит выявить кто эти люди.
кто заказал, кто ставит задачу, кто принимает работы, кто подписывает акты... почему они работают вместе.

[pitersky]

Цитата:

Сообщение от mazzy

предприятие - это коллектив
нуждаются или не нуждаются во внедрении отдельные люди.

нет, я не об этом
предприятие - это самостоятельный экономический агент на рынке. предприятие конкурирует с другими предприятиями за одних и тех же клиентов. ERP-система должна помогать выигрывать конкуренцию.

[Sancho]

"хорошо зафиксированный пациент в анестезии не нуждается"
единственное преимущество, которым обладает ERP - комплексность и удобный (аналитически) срез реальной финансовой информации в организации.
если это важно для оперативного принятия управленческих решений - это конкурентное преимущество.
если фирма производит плитку тротуарную под гос контракт, как и 30 лет назад, то нет места в принципе "управленческим решениям", отсюда да, игрушка.

- а сколько мы рабочих мест сократим когда внедрим ERP?
- еще человек 15 - 20 наберете, ассистентов продажников.

[George Nordic]

Ребят, давайте не путать внедрение ради внедрения. Если ERP внедряется "Шоб було", то, конечно, встретятся все описываемые вами проблемы, +еще работники будут работать по схеме "а чтоб они задоблались".

Если подходить к внедрению ERP с умом, то надо в первую очередь понимать, что это - автоматизация! Т.е. внедрение ERP должно разгружать людей, например, автоматизируя бизнес-процессы, а не добавляя в них путаницы.

Именно поэтому при "правильном" внедрении (а при карго-культе) где-нибудь в Арисе рисуются процессы, а потом консультанты думают над их оптимизацией, рисуются целевые бизнес-процессы, и потом под них настраивается системы. А не наоборот - внедрили, а потом "о, а так можно было?", "А, вот как оказывается нужно было!", "О как здорово, а давайте еще и вот это настроим" и "Ой, все поломали". И процессы - не просто не оптимизированы, а запутаны донельзя. А люди, вместо того бы разгрузиться, еще больше информации в систему вносят, счета там, отделы, ЦФО. Поэтому и помощники ключевым сотрудникам требуются, вместо того чтобы их разгрузить.

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

[Ivanhoe]

В качестве оффтопа про кол-во сотрудников после внедрения. Если до этого ничего не вводили в систему - то, понятно, кол-во может вырасти. Уменьшиться может только за счет автоматизации ручного труда (т.е. есть что менять на систему).

В целом давайте вернемся к теме - что делать? Партнеру, Вендору, Клиенту?

[George Nordic]

Цитата:

Сообщение от Ivanhoe

Может, в чем-то рынок AX был похож в начале / середине 2000-х?

Скорее, на начало. Т.е. 1С вышла на крупных заказчиков и сложные комплексные проекты, и столкнулась с тем, что мы проходили лет 15 назад. И это здорово: если кто-то уже проходил подобное, то накоплен опыт, сын ошибок трудных, и на него можно ориентироваться.

Кратко суммирую что писал на синьюсе:

Это старая и известная проблема. Обсуждалась более 10 лет назад теми, кто внедрял ERP системы - Axapta / Sap / Scala / Infor и т.д. Тогда 1С была известная в основном только своей бухгалтерией. Хотя уже тогда была куча конфигураций, но внедрение состояло в настройке, а сопровождение - в наличие своего программиста (он же админ, он же обучение и поддержка), а франчи - просто привозили свежий диск ИТС. Теперь 1С полноценно играет на рынке ERP, вытесняя прочих игроков, и сталкивается с тем, что многие прошли десятилетие назад - управление партнерской сетью, контроль за качеством внедрений, разделение на тех, кто просто поставляет лицензии / итс и теми, кто действительно может сделать проект, со специализациями, сертификацией и т.д.

Проблема, которую обозначил автор - глобальна, и касается не только ERP. Дело в том, что заказчик на уровне подбора команды не может сформировать требования к качеству проекта. Следовательно, кто-то всегда будет дешевле, правда, за счет качества. И выяснится это уже в ходе проекта, когда команда уже выбрана.

Ведь внедрение ERP - это не настройка 4-6-10 конфигураций, склеенных кое-как. Это единая система со сквозными бизнес-процессами. И внедрять ее ой как непросто. И мало кто умеет это делать, особенно клиенты. Откуда они знают "требования к качеству"? Кто им расскажет, "как правильно"??. Как делать предпроектное обследование, описывать функциональные и организационные требования к проекту, gap/fit анализ к выбираемой системе, правильно составлять план внедрения, ТЗ и требования к результату? Это сплошной матан для них. А тут приходи компания и говорит "а, зачем все это? сейчас adjle в моде, короче, готовьте 5 млн рублей и мы все сделаем". А потом оказывается, что на эти 5 млн рублей и ТЗ толком не напишешь, какое тут качество?

Поэтому ВЕНДОРУ приходится учить заказчиков (и партнеров, или заказчиков через партнеров) как выбирать и внедрять систему, и наводить порядок в канале.

Если вендор будет честно рассказывать про проектные риски, как правильно оценить проект и внедрить ERP-систему, и почему проект должен стоить не шапку сухарей, а вполне себе немаленькие деньги и, главное, почему это вложение разумное (как можно окупить вложения, или почему их вообще стоит делать) - это сильно поможет рынку. Этого никто не делал, так как боялся проиграть другому вендору (или партнеру). Но, в итоге, на большинстве ERP-проектов стреляли проектные риски, что приводило в сдвигам сроков проекта, запуску только части обозначенной функциональности, проект выходил за рамки бюджета и т.д. Что, в свою очередь дико раздражало заказчиков, и сформировало негативный фон к ERP в целом.

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

[ax_mct]

Цитата:

Сообщение от Ivanhoe

В целом давайте вернемся к теме - что делать? Партнеру, Вендору, Клиенту?

Цитата:

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

Дело в том, что заказчик на уровне подбора команды не может сформировать требования к качеству проекта.
...
Как делать предпроектное обследование, описывать функциональные и организационные требования к проекту, gap/fit анализ к выбираемой системе, правильно составлять план внедрения, ТЗ и требования к результату? Это сплошной матан для них.

Дело даже не в том что это матан, а в том что это мертвая материя. Клиенту нужен Agile. То что перегруженный монолит слишком сложен для Agile - это проблема продукта, а не Клиента.

Что делать? Убирать Вендора как слабое звено

[George Nordic]

Цитата:

Сообщение от ax_mct

Дело даже не в том что это матан, а в том что это мертвая материя. Клиенту нужен Agile.

Да велком. Сами будете потом клиенту объяснять "этого не было в рамках проекта".

Цитата:

Сообщение от ax_mct

Что делать? Убирать Вендора как слабое звено

Вот это свежая идея. "Взять все и поделить!"

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

[Sancho]

Цитата:

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

Как делать предпроектное обследование, описывать функциональные и организационные требования к проекту, gap/fit анализ к выбираемой системе, правильно составлять план внедрения, ТЗ и требования к результату? Это сплошной матан для них. А тут приходи компания и говорит "а, зачем все это? сейчас adjle в моде, короче, готовьте 5 млн рублей и мы все сделаем". А потом оказывается, что на эти 5 млн рублей и ТЗ толком не напишешь, какое тут качество?

вот не соглашусь
в бытность работы рафинированным бизнес аналитиком приходилось писать функциональные требования и ТЗ. напишешь на трех страничках - косо посмотрят, так "каждый дурак" может.
допустим, описание функций отдела или процесса закупки получается на 80 - 140 страничек.
и требует 10-ти виз на листочке согласований.
и все знают, что если поставят свою визу, то потом их могут нагнуть.
следовательно, читают долго.
+ просят внести изменения, после которых запускаем новый виток согласований.
в итоге через полгодика топики процесс согласовали... а бизнес УЖЕ УШЕЛ!!! а разработка еще не начиналась! уже новые финансовые схемы, уже прошла маленькая реорганизация и из отдела закупок теперь появилось 3 отдела.
и можно аккуратно порвать 140 страничек и сесть писать заново.

приходила в голову мысль сразу под принтер шредер ставить... хотя бы время топиков сэкономить.

так вот ТУТ я никакого КАЧЕСТВА не вижу.

и таки да, я за Agile, при котором всегда не поздно свернуть.

а в примере за это время были бы потрачены 5 лямов и была бы РАБОТОСПОСОБНАЯ и ОТТЕСТИРОВАННАЯ часть системы, пусть 20 или 80 процентов

[Bobkov]

Цитата:

Сообщение от Ivanhoe

В целом давайте вернемся к теме - что делать? Партнеру, Вендору, Клиенту?

Спасибо за вопрос. Попробую поотвечать

Для партнеров автор формулирует проблему так:
"на тех проектах, которые партнеры «1С» выигрывают, они получают потенциально меньшую маржу, чем в случае с неценовой конкуренцией."

Похоже на то, что они получают меньшую маржу, зато захватывают рынок и добирают потом эту маржу последующей деятельностью на клиенте.
Мне кажется, проблема партнеров в статье сформулирована наиболее слабо, автору стоило бы подробнее ее определить, а не сразу переходить к анализу и предложениям.

Для вендора автор формулирует проблему так:
"сложившаяся ситуация портит репутацию всех решений «1С» и приводит к тому, что часть потенциальных клиентов выбирают решения конкурентов."
А вендор отвечает: "эта проблема общая для всех поставщиков ERP-систем."

И с ним трудно не согласиться. Насколько я вижу по публикациям в СМИ - вендору сейчас хорошо. С действующим подходом он продолжает захватывать рынок. Следовательно, его подход адекватен состоянию рынка. Почему он сейчас должен что-то менять в своей работе? Целесообразность перемен в подходе вендора для меня далеко не очевидна.

Для клиентов автор формулирует проблему так:
"проекты по внедрению «1С:ERP» проводятся неэффективно: не укладываются в бюджет и не дают желаемых результатов."

Как раз этот вопрос я пытался осветить в статье, ссылку на которую давал выше.
Клиентам, которые хотят получать желаемые результаты в рамках бюджета, надо в первую очередь научиться предъявлять требования к автоматизированным системам и контролировать их выполнение, а не надеяться, что это сделает партнер или вендор. Так как и партнер, и вендор конечно помогут, но непременно в свою пользу. В общем, спасение утопающих - дело рук самих утопающих, и не надо пытаться спихнуть этот головняк на 1С, что пытается сделать автор статьи, IMHO.

Также заказчикам можно пользоваться внешним консалтингом, независимым от внедренцев. Но тогда придется научиться искать и выбирать таких консультантов, что может быть еще сложнее, чем научиться управлять требованиями к автоматизированным системам.

Если заказчики захотят спасаться сообща, то я вижу логичным им создавать отраслевые ассоциации, которые оказывали бы членам консультативную помощь по управлению требованиями к автоматизированным системам.

Цитата:

Сообщение от Sancho

и таки да, я за Agile, при котором всегда не поздно свернуть.

Agile это по сути требование, что в проекте должны быть выделены относительно короткие "пусковые очереди", как это называлось в советское время, и детальное проектирование должно вестись в рамках каждой очереди отдельно, а не разом. То есть, это просто одно из требований к проекту, вполне разумное на мой взгляд, если без фанатизма, но не отменяющее необходимости определения остальных требований к системе!

Цитата:

Сообщение от ax_mct

Что делать? Убирать Вендора как слабое звено

Прекрасно! Твоя реплика напомнила мне одного замечательного персонажа:
https://www.youtube.com/watch?v=9Gsm9HOUGtg