Отраслевое решение - стереотип или нет?

[fed]

Цитата:

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

Вывод: Каждый партнер должен копить (в идеале) - некий опыт в виде несложных (затрагивающих мало объектов) модификаций, которые должен хорошо документировать и которые должны стопудово всем подходить и все сотрудники партнера стопудово должны знать эти модификации (т.к. они маленькие) - с т.з. функциональности.
Соответственно - приходя к очередному клиенту - продается (это даже решением назвать нельзя) некий "сервис-пак" (с) BOAL, в котором накоплен опыт партнера - и в который включено 99% востребованных клиентом модификаций (сразу скажу - модификации точно должны быть не отраслевыми). В

Хороший бизнес план !
Если мне его принесут (как бы я финдир) я задам такие простые вопросы:
1. Предложите способ выделения из проектных модификаций тех самых "стопудово всем подходящих" и 99% востребованых.
2. Оцените стоимость интеграции модификаций, собранных в единый слой с разных проектов.
3. Подсчитайте стоимость их переноса на все выходящие обновления. (Раз в полгода примерно).
4. Подсчитайте экономический эффект от их применения.
5. Оцените риск того, что они будут несовместимыми с следующими версиями. (как показывает ситуация с DAX 2009 - риск высокий).

Жду твоей арифметики

[Serg]

to fed
По поводу бизнес плана, выделить такие доработки совсем не сложно и обосновать их экономическую целесообразность то же.

Пример.
Закрытие складе по «средней».
Всем известно, что Axapta закрывает с некой оговоркой, что стоимость расхода будет приближенной и чем выше растет цена текущем периоде, относительно предыдущего тем выше отклонение от стандартного метода расчета, которые делают бухгалтера и налоговые инспектора. С учетом текущего уровня инфляции можно прикинут отклонения.
Всем бухгалтерам и налоговым инспекторам известно, что метод закрытие по средней самый легкий и единственно возможный для проверки корректности его расчета. Для чего достаточно скинуть оборотку по складу в Excel и «протянуть» всем известные формулы.
Надеюсь многим должно быть известно, что излюбленный метод расчета себестоимости на производственных предприятиях с процессным типом про-ва это метод «средней» так как он позволяет упростить калькуляцию производственной себестоимости готовой продукции и полуфабрикатов. Помимо этого преимущество метод средней обладает положительной временной разницей относительно налога на прибыль.

Теперь осталось сделать небольшое заключение – что многие предприятия будут отказываются брать на себе практически 100% налоговый риск связанный с нарушениями правил ведения бухгалтерского учета, а именно использования метода средней в Аксапте.

Теперь о выгодах и потерях, по одному клиенту, Microsoft потерял как минимум порядка 1 млн $ на лицензиях в этом году.

Когда партнер Microsoft приведет в соответствие расчет средней к методу изложенному в правилах БУ и включит его в отраслевое решение, он займет лидирующее положение на рынке про-ных предприятий с процессным про-ва.

Так что поддерживать решения партнерам не просто выгодно, а иногда единственно возможный вариант оставаться на рынке.

[Raven Melancholic]

Цитата:

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

to fed
Когда партнер Microsoft приведет в соответствие расчет средней к методу изложенному в правилах БУ и включит его в отраслевое решение, он займет лидирующее положение на рынке про-ных предприятий с процессным про-ва.

Правда это уже будет не отраслевое, а универсальное решение.
Но Microsoft уже опередило партнёров, изменив в DAX2009 метод расчёта по средней

[fed]

Цитата:

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

to fed
По поводу бизнес плана, выделить такие доработки совсем не сложно и обосновать их экономическую целесообразность то же.

Расскажи как ?
Я просто неоднократно наблюдал попытки (причем у разных партнеров, а не только в том в котором я работал), собрать общий слой с доработками. Сценариев всего этого было два: Либо манагеры проектов разругивались на стадии утверждения списка доработок; Либо слой разрабатывался в отрыве от проектов (и их манагеров) и быстро становился бесполезным...
То есть - мое негативное отношение к всяким попыткам делать НЕПРОЕКТНЫЕ доработки сформировалось по итогам наступания на большое количество граблей...

Кстати - я так или иначе участвовал где-то в 20 проектах. Среднюю однажды переписывал. На остальных проектах - не понадобилось. Кто-то на FIFO жил, кто-то на партионной, кто-то довольствовался той средней, которая есть...

[Serg]

Процедура всем известная пресловутый базовый слой, несмотря на все недостатки и споры менеджеров проектов, это гораздо лучше, чем начинать внедрять со стандартного слоя, ибо он практически не пригоден к внедрению. Споры снижаются, кода эту работу возглавляет высоко квалифицированный специалист. На последнем проекте пришлось потратить около 9 месяцев на перенос и исправления ошибок переноса базовых доработок на стандартную 4-ку. Так что для партнеров это далеко не бесполезная работа. Честно говоря, меня настораживает быстрый выход 5 версии, с учетом заявленного объема доработок мало кто из партнеров потянет, что бы ее довести до приемлемой кондиции.

Все как локализацию так и отраслевые решения конечно лучше формировать непосредственно в Microsoft – организовать соответствующие отделы Best Practices по отраслям, платить тем же партнерам за их доработки с обязательным отраслевым аудитом выездом на проекты. SAP поступает конечно круче он вообще все доработки заставляет регистрировать у себя и иногда может отказывать.

[EVGL]

Цитата:

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

...меня настораживает быстрый выход 5 версии...

А кто сказал про быстрый выход русской версии?

[natterru]

Сорри на некоторый оффтоп.

Цитата:

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

А кто сказал про быстрый выход русской версии?

Вам что то известно про дату выпуска руссиш 5-ки?

[mazzy]

Цитата:

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

Сорри на некоторый оффтоп.

Вам что то известно про дату выпуска руссиш 5-ки?

Не надо оффтопа. Вы уже спрашивали. Вам ответили.
AX2009 has been Released
Большей информации пока в публичном доступе нет.

[fed]

Цитата:

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

На последнем проекте пришлось потратить около 9 месяцев на перенос и исправления ошибок переноса базовых доработок на стандартную 4-ку. Так что для партнеров это далеко не бесполезная работа.

Я вот базовым слоем никогда не пользовался. При запуске очередного проекта просто собирали полезные модификации с последних нескольких проектов. Занимало это порядка месяца-полутора (с отладкой и вылавливанием граблей комплексирования). А тут - оказывается 9 месяцев потрачено. А потом Микрософт выпустит новый service pack или не к ночи будет сказано - новую версию. И что - снова 9 месяцев переносить ?
Как насчет сроков окупаемости затрат на перенос ? Сколько проектов надо стартовать с этого слоя, чтобы затраты на перенос на очередной sp окупились ? Кто из партнеров в России каждый год стартует достаточное количество новых проектов чтобы окупить затраты на перенос базового слоя на каждый выходящий SP или новую версию ?


То есть- предлогаю для дальнейшей дискусии разделить два понятия:

• Общий слой (базовый или какой еще)
• Библиотеку наработок. (В виде xpo-шек, know-how, документации по доработкам и тп).

Против библиотеки наработок никоем образом не спорю. А вот базовый слой - штука невыгодная...

[mazzy]

Цитата:

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

Как насчет сроков окупаемости затрат на перенос ? Сколько проектов надо стартовать с этого слоя, чтобы затраты на перенос на очередной sp окупились ? Кто из партнеров в России каждый год стартует достаточное количество новых проектов чтобы окупить затраты на перенос базового слоя на каждый выходящий SP или новую версию ?

Сов. Согласен

[Serg]

To Mazzy… Закрытие склада это всего лишь оценка расходов по одному из методов. Калькуляции призвана собрать расходы и дать ответ по структуре себестоимости ГП (сколько вне прямых и косвенных затрат, на какие статьи они разбиваются и какие элементы содержат). Калькуляция связана с закрытием склада лишь в части списаниям ТМЦ на затраты, но помимо затрат на ТМЦ в нее входят масса других элементов. Пример полуфабрикатов на складе 10 партий (естественно с полной структурой себестоимости от зарплаты основных рабочих до стоимости сырья еще на первых переделах и первых составляющих этого полуфабриката, естественно складские проводки в Аксапте эту структуру не хранят и для этого используются другие инструменты). Теперь представь, что гораздо проще посчитать стоимость расхода этих полуфабрикатов с протаскиванием их полной структуры по средней на следующий передел, чем по каждой партии выполнять данных расчет.
Скорее всего судя по твоему посту….ты ни когда не занимался калькуляцией на про-ве.

To Fed
По 1-1,5 месяца это ни о чем. Тем более речь идет о новой версии, возьмите, к примеру в 4-ке заказы на перемещение – какие там печатные формы накладных были? Правильно ни каких. А сколько надо – как минимум 2 Торг13 и ТТН, а по хорошему еще парочку. А как дела обстоят с синхронизацией складских аналитик? Опять ни как. А что делать, если по ходу маршрута склад назначения был изменен? Правильно ни чего не поделаешь. А где взять залоговые цены для транспортных компаний? Опять ни где и т.д. и т.п. Теперь объем доработок по только одному системному объекту умножим на кол-во проектов и получается экономия. А теперь представим, сколько таких объектов в системе исправляется? Получим весьма хорошую экономию.

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

Меня на самом деле волнует базовый слой больше чем отраслевая специфика.

[mazzy]

Цитата:

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

Закрытие складе по «средней». ... Axapta закрывает с некой оговоркой, что...

Всем бухгалтерам и налоговым инспекторам известно, что метод закрытие по средней самый легкий и единственно возможный для проверки корректности его расчета. Для чего достаточно скинуть оборотку по складу в Excel и «протянуть» всем известные формулы.

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

Вы путаете кисло с пресным. Для того, чтобы удовлетворить бухгалтеров и налоговых инспекторов такое дорогое решение как Аксапта не нужно. Вы сами говорите про Excel. А вот для предотвращения мордобоя и стрельбы - само то.

Цитата:

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

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

Нет, конечно. Еще более "упростить калькуляцию" позволяет метод плановой себестоимости (в Аксапте он назвается стандартной себестоимостью). Беда только в том, что для его использования все должны быть согласны с выбранной плановой себестоимостью для всех номенклатур с данным методом расчета. А вот получить "согласие" без мордобоя сложно. Для этого и нужна Аксапта - дать обоснованно рассчитанную себестоимость для всех акционеров/владельцев.

Цитата:

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

Теперь осталось сделать небольшое заключение – что многие предприятия будут отказываются брать на себе практически 100% налоговый риск связанный с нарушениями правил ведения бухгалтерского учета, а именно использования метода средней в Аксапте.

Как скажете

Цитата:

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

Теперь о выгодах и потерях, по одному клиенту, Microsoft потерял как минимум порядка 1 млн $ на лицензиях в этом году.

Вы хотите сказать "не получил"?

Цитата:

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

Когда партнер Microsoft приведет в соответствие расчет средней к методу изложенному в правилах БУ и включит его в отраслевое решение, он...

...он тут же потеряет возможность получения отчета по структуре стоимости и структуры себестоимости.
Serg, может быть вам стоит еще чуть-чуть разобраться почему и зачем Аксапта закрывает склад именно так. А также ответить (хотя для себя) зачем нужно связывать каждый приход с каждым расходом и куда при этом девается "простота Excel".

Цитата:

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

Так что поддерживать решения партнерам не просто выгодно, а иногда единственно возможный вариант оставаться на рынке.

Ну... Если партнер ТАК переколбасит логику работы, то конечно ему останется единственно возможный вариант

Цитата:

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

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

Может быть, стоит научиться его готовить?

Цитата:

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

На последнем проекте пришлось потратить около 9 месяцев на перенос и исправления ошибок переноса базовых доработок на стандартную 4-ку. Так что для партнеров это далеко не бесполезная работа.

Цитата:

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

Честно говоря, меня настораживает быстрый выход 5 версии, с учетом заявленного объема доработок мало кто из партнеров потянет, что бы ее довести до приемлемой кондиции.

Ну, если поднимать ТАКИЕ модификации, то вы конечно правы.
Но мне кажется, что слой "русефеикации" наоборот можно и нужно уменьшать. Слишком много там лишнего... Примерно из той же серии, как ваше "среднее".

Цитата:

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

Все как локализацию так и отраслевые решения конечно лучше формировать непосредственно в Microsoft

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

[sukhanchik]

Ой.. какую дискуссию я породил... Прям неудобно - напоминает спор о том - что лучше - 1С или Аксапта
Извиняюсь за задержку в ответе - времени не было.
Итак, мне задали вопросы - надо ответить

Цитата:

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

Хороший бизнес план !
Если мне его принесут (как бы я финдир) я задам такие простые вопросы:
1. Предложите способ выделения из проектных модификаций тех самых "стопудово всем подходящих" и 99% востребованых.

Ну это я думаю не так сложно. Если есть какие-то модификации (в т.ч исправление багов), реализованные на N проектах (минимум 2) - то эти модификации - являются кандидатами на включение в "слой". Если модификации - являются общими более, чем на 5 проектах - то имеет смысл их включить в "слой". С большой долей вероятности - в 6-м проекте - модификация снова будет востребована.
И то - надо понимать - что 5 проектов по логистике не равны 6-му по финансам.
По сути - должен быть некий эксперт, который своим субъективным мнением должен определять "попадание в слой". Я пока не готов предложить объективную оценку .

Цитата:

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

2. Оцените стоимость интеграции модификаций, собранных в единый слой с разных проектов.

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

Цитата:

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

3. Подсчитайте стоимость их переноса на все выходящие обновления. (Раз в полгода примерно).

Вот тут вопрос ооочень философский. Обновление обновлению рознь. Сразу скажу - я не сторонник подъема на каждый сервис-пак (не то что на какие-то там хотфиксы). Лучше - через один. Да и независимо от наличия "базового слоя" - работы по анализу необходимости этого сервис-пака никто не отменял. Если отталкиваться от множества небольших модификаций, то:
а) на сервис-пак можно забить - вышестоящие слои перебьют его (очевидно - это решение должно приниматься очень ответственно)
б) на сервис-пак можно не торопиться пониматься (начинать проект с предыдущим СП)
в) на сервис-пак можно не подниматься, но перенести отдельные нужные модификации (если их мало)
г) на сервис-пак можно подняться.
Для каждого варианта надо просчитать экономический эффект - в зависимости от того - что поменяли в сервис-паке и от того - что лежит в "базовом слое" - что дешевле (что займет меньше человеко-часов и что меньше отразится на дальнейшем сопровождении).

Цитата:

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

4. Подсчитайте экономический эффект от их применения.

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

Цитата:

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

5. Оцените риск того, что они будут несовместимыми с следующими версиями. (как показывает ситуация с DAX 2009 - риск высокий).

А вот тут-то могу позволить не согласиться. Кто сказал - что надо бежать всем на новую версию? Надо еще со старой разобраться. Да фиг с ней с поддержкой от Микрософт - она много дает? С 3-шкой - подписываться на обновления было невыгодно - 4-ка дешевле стоит, нежели 3-шка со всеми обновлениями.
Да, риск большой. Я считаю - что надо задумываться о новой версии - когда из старой все будет выжато по максимуму. Яркий пример - 4-ка. Ну и кому нужен переход с 3-шки на 4-ку - когда уже маячит 2009-я? Ну кроме конечно партнеров, консультантов и прочих лиц, которые с этого кормятся? Или же можно провести аналог - Win XP - Win Vista. А тут уже вполне можно смотреть на систему - как на новую - и заново ее внедрять. Уверен - что переход с 3-шки на 2009-ку будет стоить гораздо дешевле (раза в 2 точно), чем переход с 3-шки на 4-ку и с 4-ки на 2009-ку.

В заключение могу сказать - что я не привел ни одной цифры - которой от меня так ждали. Не могу. Это надо считать для каждого приложения по-своему. Оценивать все модификации по сервис-пакам в применении к заказчикам (причем к каждому) - тут работка даже не на день. Возможно, цифры - докажут обратное. Но что-то пока собственная интуиция говорит об обратном.
Кстати - никто не может знать (ну может кроме Микрософта) - а какова вероятность совместимости 2009-й со следующей версией. И если такая же как у 3-шки с 2009-й (т.е. практически никакая) - то это значит - что каждое такое обновление равносильно внедрению с нуля.

И еще хочу заметить про базовый слой. Он нужен - для работы на проектах в рамках одной версии. Микрософт не будет никогда (я надеюсь ) делать кардинальные вещи в сервис паках. Он оставит их до выпуска новой версии. А значит хотя бы полусовместимость базового слоя (см мои пункты а, б, в, г) все равно будет.
И опять-таки - он оправдан - при большом (>5) количестве разных клиентов, хотящих одно и тоже (очень сильно похожее). Если за время жизни 4-ки к примеру - партнер не найдет такого количества клиентов (а будет например окучивать одного большого клиента в разных областях) - то очевидно - что ему этот слой не нужен

[miklenew]

Кто нибудь скажет что такое базовый слой, а то чё-то не пойму.

[mazzy]

Цитата:

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

Кто нибудь скажет что такое базовый слой, а то чё-то не пойму.

Это понятие было введено в этой ветке.
Отраслевое решение - стереотип или нет?

[miklenew]

Цитата:

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

Это понятие было введено в этой ветке.
Отраслевое решение - стереотип или нет?

Правильно ли я понимаю, если внедрение идёт на прилаге отличающейся от стандартной, то это либо базовый слой, либо сертифицированное решение?
Отличающиеся лишь тем, что первое не сертифицировано.