Консалтингу не выгодна разработка

[mnt_dx]

Цитата:

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

Была бы одна кнопочка на каждой мобилке "Заплатить за консалтинг" и все.

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

[GBH]

Цитата:

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

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

Да нет, это и есть реалии консалтинга в России. В частности в СПб. Уровень 80% консультантов и программистов такой, что лучше бы от них избавились. Но не избавляются, а проталкивают свои "решения". Т.е. после обучения(причем в основном обучают решению, а не стандарту и правилам учета) , в лучшем случае месяца два, сразу на проект. Внедрять решение партнера.
Поэтому соглашусь с коллегой macklakov , что консалтингу очень хотелось бы иметь такую кнопочку и спор, действительно, не понятен. Опять сейчас будет куча постов какие же консалтеры профи, а клиенты их не понимают. И все проекты, практически, убыточны, но из-за врожденного альтруизма всё равно внедряют.

[mnt_dx]

Это разные виды бизнеса: кто-то осуществляет pure-консалтинг, кто-то конс+девелопмент, а кто-то просто кладет деньги в банк и получает процент.

[ax_mct]

У очень известной консалтинговой компании в договорах стоит такая штука - если в течение двух недель вы не пожаловались на наш баг то мы его пофиксим за ваши деньги. И да в таком виде может быть и выгодно для компаний у которых уже незыблемая репутация даже если и колбасят там программисты с годом опыта. Это так из больного на этой неделе.
Я плюнул в них ядом как мог. Но подход заценил.

Это я к тому что если репутация не важна или непоколебима то можно и попрограммировать.

[ax_mct]

Моя компания по сути есть компания-разработчик. Я делаю деньги на программировании в AX. И это не что иное как услуги по IT consulting так как одним кодингом дело никогда не ограничивается. 
И мне это выгодно и нет в этом ничего нечестного или грязного. 

Однако с тезисом "Консалтингу не выгодна разработка" я согласен на все 100%. Уверен что речь в данном тезисе об идеальной или ближе к идеальной модели бизнеса как если бы мы сравнивали торговлю физическим товаром с физического склада или торговлю электронным товаром без необходимости складского учета. 

Мнение такое основано не на теориях бизнеса а на практическом опыте. Итак, более удобная или более профессиональная модель Консалтинга стремится избежать разработок на клиенте во время внедрения.

Любая разработка увеличивает риски. Выгоднее внедрять коробку без программирования на клиенте. Просто более идеальная модель Консалтинга.

[Pustik]

Присоединяюсь к Дмитрию. Голый и ничем не окученный функционал - это просто-напросто выжим денег из клиента, с красивыми словами "Все будет хорошо". Есть здесь специалисты, которые внедряли такое чудо ? Я имею ввиду: приехали , проинсталлировали стандарт, накатили свои ранее "успешно внедренные" модули ,проверили на 3-х записях и уехали, подписав нужные бумаги? К сожалению, лично мне пришлось с этим столкнуться. Переписывание модуля под стандарт предприятия не вызвало у меня сильного восторга.

[fed]

Я ни разу не видел внедренного стандарта (пусть даже с минимальными модификациями типа интеграции с внешним ПО типа клиент-банка). Просто если этот стандарт расширять, а не переписывать (чем обычно партнеры и занимаются), то можно внедрить малой кровью, с разумными затратами на разработку/отладку/поддержку. Проблема в том, что этот стандарт мало кто понимает, соответственно - в 90% случаев (кстати и за пределами России тоже), разработка сводиться к тому чтобы переписать весь функционал, который консультанты не поняли или не смогли объяснить клиенту...
Вопрос то не в том чтобы внедрить без дописывания, а в том чтобы найти оптимум между дописыванием и изменением бизнес-процессов клиента (что тоже вообще-то большие затраты и риски несет).

[Pustik]

Цитата:

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

Просто если этот стандарт расширять, а не переписывать (чем обычно партнеры и занимаются)

Золотые слова

[Мартынов Дмитрий]

Цитата:

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

Золотые слова

Ну в этом вопросе у нас тут консенсус.

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

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

[fed]

Цитата:

Сообщение от Мартынов Дмитрий

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

Приведенный тобой конкретный пример как раз таки говорит о крайнем бардаке в учете у заказчика. И вместо того чтобы их хоть как-то наставить на путь истинный (например - предложить им признавать задолженость по получению счета от клиента), консультант переписывает систему так чтобы задолженость рассчитывалась вопреки минимальному финансовому смыслу. Очень наглядная иллюстрация к тезису о том что 90% разработок - от непонимания...

[Мартынов Дмитрий]

Цитата:

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

Приведенный тобой конкретный пример как раз таки говорит о крайнем бардаке в учете у заказчика. И вместо того чтобы их хоть как-то наставить на путь истинный (например - предложить им признавать задолженость по получению счета от клиента), консультант переписывает систему так чтобы задолженость рассчитывалась вопреки минимальному финансовому смыслу. Очень наглядная иллюстрация к тезису о том что 90% разработок - от непонимания...

Не надо смешивать обязательства и задолженность, это разные вещи. Может быть вас сбило с толку слово "ведомость".

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

[fed]

Кроме того - отношение консалтинга к доработке зависит еще и от того, как продали проект - на почасовке или на фикс-прайсе. На фикс-прайсе - доработка заведомо невыгодна, поскольку несет риски и затраты. На почасовке (хотя как-то она в России редко попадается) - доработка выгодна в разумных пределах. Потому что после очень большой доработки систему уже тяжело запускать и внедрять становиться, и рано или поздно наступает момент когда клиент требует запуска системы и отказывается платить... (И тыкать его носом в подписанные им дизайны и протоколы становиться бесполезно).

[sukhanchik]

Цитата:

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

Кроме того - отношение консалтинга к доработке зависит еще и от того, как продали проект - на почасовке или на фикс-прайсе.

В теории - да, но почасовые допсоглашения еще никто не отменял . Они как раз и нивелируют плюсы от фикс-прайса. Ну... при большом объеме ДСок конечно.

[Pustik]

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

[Pustik]

Дмитрий, согласен с Вашим мнением. Хочется уточнить одну деталь. Как бы Вы правильно не думали, найдутся люди, которые посчитают, что ваше мнение ошибочно.Не из за того , что оно действительно ошибочно, а из за того, что эти люди находятся на ступень выше Вашего социального положения.Спорить и что-то доказывать, я думаю сами понимаете бесполезно. Так и получается , что круглое неси, а квадратное катай.

[ax_mct]

Есть на свете "здоровый" образ жизни но мало кто ему может следовать. Так и здесь.
Тема лишь о том что "здоровее" а не том что у конкретных людей нет возможности ей следовать.
То есть о более идеальной модели Консалтинга которой следовать могут не все и не всегда.

Коробка не означает стандарт. Чаще всего это отраслевое или вертикальное решение.

Да невозможно избежать разработки вообще но можно сознательно играть на их уменьшение осознавая что это зло. Часто залог успешного запуска это именно политика подавления стремления попрограммить. То есть risk management.

Дмитрий,
Не в том дело чтобы отказывать клиенту в разработках, а в том чтобы делать их как можно меньше особенно на этапе запуска. Чем более опытный Консалтинг, тем меньше программирования на клиенте. Если конечно речь не о разработке вертикального решения на данном клиенте.
Стоимость услуг консультанта это вопрос никак не связанный с данной темой. Если конечно не оценивать консультанта как постановщика задач на программирование. Но я так данную роль не оцениваю.

[Мартынов Дмитрий]

Цитата:

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

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

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

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

[ax_mct]

Плох тот консультант который предлагает
что-то решить через по-программировать. То есть как минимум половина кастомизаций от незнания функционала а вторую половину неплохо бы делать только после запуска и с помощью другой компании. Это так с точки зрения Идеала

[gudzon]

Цитата:

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

Плох тот консультант который предлагает
что-то решить через по-программировать.

Какие то идеальные консультанты на идеальных проектах у идеальных клиентов. Ваше "что-то" находится в очень широком диапазоне. И объясните толком чем плохо программировать то. А то я как то не встречал проекты без кодинга. Может не так что то делаю.

[ax_mct]

Цитата:

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

Какие то идеальные консультанты на идеальных проектах у идеальных клиентов. Ваше "что-то" находится в очень широком диапазоне. И объясните толком чем плохо программировать то. А то я как то не встречал проекты без кодинга. Может не так что то делаю.

Не плохо. Речь о том чем меньше программирования тем лучше.
Да и тема скорее про то что для Консалтинга программирование это зло. Часто неизбежное. С позиции владельцев такого бизнеса.