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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

[Pustik]

Цитата:

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

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

Мне кажется, что цель состоит в том, чтобы обеспечить клиента полноценно работающим функционалом на определенный срок, без вызова стороннего программиста, который будет исправлять баги, выявленные в процессе ОПЫТНОЙ эксплуатации.И отговорки "нам за 2 часа работы в САП платят больше, чем здесь за 2 дня" должны инкреминироваться как не качественное выполнение работ.

[ax_mct]

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

[ax_mct]

Цитата:

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

Мне кажется, что цель состоит в том, чтобы обеспечить клиента полноценно работающим функционалом на определенный срок, без вызова стороннего программиста, который будет исправлять баги, выявленные в процессе ОПЫТНОЙ эксплуатации.И отговорки "нам за 2 часа работы в САП платят больше, чем здесь за 2 дня" должны инкреминироваться как не качественное выполнение работ.

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

[gudzon]

Цитата:

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

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

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

[ax_mct]

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

Все доехал до клиента (5 часов сидя в поезде), ушел в ненавистное программирование... Главное руки потом помыть

[fed]

Цитата:

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

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

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

Насколько я помню IAS/GAAP, там вводится понятие "принципе осмотрительности", в соответствии с которым обязательства и убытки признаются в момент возникновения, даже если они не подтверждены конкретными документами. Соответственно если китайские поставщики при нарушении этих обязательств отказываются работать дальше, то необходимо эти обязательства принять к учету. Обычно для этого задолженость разноситься на некий промежуточный счет, на котором и живет. По прибытии товара, оприходование случается не со счета задолжености, а с этого промежуточного счета. Если присланная накладная оказалась чуть больше или меньше предварительно проведенной задолжености, то либо проводиться дополнительная (маленькая) задолженость, либо старая задолженость сторнируется в текущем периоде и проводится заново (в текущем периоде опять таки) с новой суммой.

Это я к тому, что независимо от степени "управленческости" учета, так сказать, следование некоторым фундаментальным принципам GAAP/IAS весьма полезно. Возможно тогда как раз удастся внедрить модуль рассчетов с поставщиками, расширяя его, а не переписывая отчетность по задолженостям с ноля...

[ax_mct]

Цитата:

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

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

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

[gudzon]

Цитата:

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

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

Не особо знаком с консалтингом со стороны владельца. Отчего не выгодно то? Вроде у программистов ставка не меньше чем у консультанта.

[veps]

и не только консалтингу, бизнес тоже считает деньги.
После покупки компанией Heineken завода Амур-Пиво в Хабаровске и последующего тиражирования проекта SAP, на заводе закрыли линию по производству бутилированной питьевой воды, т.к. в системе отсутствовали номенклатуры, не были описаны и проработаны алгоритмы расчета себестоимости в SAP и понадобилось бы программировать :-)

[fed]

Цитата:

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

Не особо знаком с консалтингом со стороны владельца. Отчего не выгодно то? Вроде у программистов ставка не меньше чем у консультанта.

В краткосрочной перспективе - разработка выгодна, поскольку помогает поднять побольше денег с клиента (в случае почасовки вообще легко, в случае фикса - с помощью допсоглашений - менее легко, но реально). В долгосрочной перспективе, избыточная разработка снижает шансы на запуск и завершение проекта. После некоторого числа доработок, затраты на комплексирование и отладку растут квадратически, в то же время выручка растет линейно. А после некоторого количества ошибок и факапов - клиент начинает упираться с оплатой (даже если формально это почасовка) или вводить требование бесплатного исправления ошибок.
Кроме того, в нормальных экономиках, те фирмы которые факапят слишком много проектов, со временем вымываются с рынка. (Конечно - не везде, не всегда, не на 100%, но в целом тенденция присутствует).
Так что избыточная разработка - это хорошо в краткосрочной перспективе и плохо в долгосрочной...

[gudzon]

Цитата:

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

Так что избыточная разработка - это хорошо в краткосрочной перспективе и плохо в долгосрочной...

Спасибо. Ну избыточная деятельность это всегда плохо. Будь то разработка или консалтинг. Но ведь и без программирования можно завалить проект. Особенно если жестко насаживать клиента на голую аксапту, мотивируя это тем, что мы не можем контролировать риски разработки. А вот следить за разработкой надо точно. Разработка в рамках предусмотренных часов по контракту вполне себе нормальное дело. Не вижу причин бояться кодинга как такового при обоюдном согласии сторон.

[Pustik]

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

[Ivanhoe]

Цитата:

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

Не особо знаком с консалтингом со стороны владельца. Отчего не выгодно то? Вроде у программистов ставка не меньше чем у консультанта.

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

Насколько я знаю, есть разные подходы среди партнеров МС - и полное выделение команды на проект, и выделение людей (в т.ч. консов) под конкретные "разовые задачи". Что в итоге оправданнее, покажет время

[Ivanhoe]

Цитата:

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

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

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

Изначально тема - про Консалтинг (и даже не совсем про Ax, про Ax условие появилось позже).

[fed]

Цитата:

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

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

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

Ну и надо помнить, что есть отрасли на которые Аксапта в принципе не становиться с разумным уровнем доработок (типа непрерывки например). Конечно можно ее переделывать, но скорее всего это ничем хорошим не кончиться. Лучше такому клиенту просто не продавать аксапту (опять таки - лучше в долгосрочной перспективе. В краткосрочной перспективе - лучше продавать кому угодно, а потом валить из фирмы-продавца с премией полученной за продажу ).
(Дисклеймер - про процессное производство в DAX2012 - знаю. Лично не внедрял. Уверен что до DAX версии 8, оно будет малость кривоватым и лучше с ним не связываться...)

[Pustik]

Цитата:

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

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

Если вырезки, которые связаны с темой,превращать в отдельные ветки, то потом можно запутаться, Вы со мной не согласны?

[Pustik]

to fed
как всегда грамотно и по делу. Очень информативно сказано, для рынка. Некоторым людям да эти слова в уши.

[Ivanhoe]

Цитата:

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

Если вырезки, которые связаны с темой,превращать в отдельные ветки, то потом можно запутаться, Вы со мной не согласны?

Не согласен. Общий подход форума - обсуждать не все подряд, а создавать отдельные темы. В отдельной теме с удовольствием поделюсь своим видением отраслей, применимостью AX и т.п.