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

[mazzy]

Цитата:

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

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

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

[Serg]

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

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

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

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

[fed]

В общем - по поводу базового слоя картина такая: Я очень часто слышу про экономию на стоимости внедрений, стоимости поддержки и т.п. Я заметно реже слышу про затраты на комплексирование, на перенос с версии на версию, на накладные расходы на поддержание организационной структуры ведения базового слоя. И я НИ РАЗУ НЕ видел нормального технико-экономического обоснования выгодности применения базового слоя. С нормальными финансовыми рассчетами и обоснованием ROI.
А раз такого обоснования нету - дык и повода для обсуждения нету. Раз нет оценок ни выручки (или сэкономленых затрат), ни рисков - значит нет повода для инвестиционного решения.

Можно конечно относится к разработке базового слоя как к венчурному проекту - но боюсь что у партнеров несколько другая бизнес-модель.

[fed]

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

Цитата:

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

[Serg]

Если отсутствие элементарных форм является «правильной» идеологией и это звучит от сотрудников Microsoft. То дискуссию действительно стоит заканчивать.

[fed]

Мне вот почему-то казалось что axforum предназначен для обмена ЧАСТНЫМИ мнениями специалистов по Dynamics AX. Я высказываю свое частное мнение и как-то мне кажется что должно быть все равно где я работаю.
Ответа на свои вопросы по поводу рассчета экономической эффективности базового слоя я так и не получил...

[natterru]

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

Нет. Не "всего лишь". Ищите, читайте. Много писалось.

Цитата:

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

Скорее всего судя по твоему посту….ты ни когда не занимался калькуляцией на про-ве.

[mazzy]

Цитата:

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

Если отсутствие элементарных форм является «правильной» идеологией и это звучит от сотрудников Microsoft. То дискуссию действительно стоит заканчивать.

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

Что могу сказать:
1. Да в Аксапте есть своя логика
2. Да эта логика отличается от того, что ожидают многие.
3. Да некоторые консультанты и пользователи вьезжают, а некоторые не вьезжают и считают "неправильным отсутствие элементарных форм".
4. НО это не значит что Аксапту надо перепахивать как это сделано в русском слое. Это значит Аксапту надо сделать доступнее, понятее. И может быть расширить логику так, чтобы она работала в большем диапазоне ожиданий.
5. Русской специфики нет. В России и в СНГ те же самые вопросы и проблемы, что у проклятых буржуев. Может быть, скомбинированы чуть по-другому.

6. Отраслевым решением может быть не только и не столько куча кода (который 9 месяцев поднимается на следующую версию). Отраслевым решением может быть:
6.1. Измененный перевод
6.2. Измененная документация и хелпы
6.3. Преднастроенная нулевая база (с настройками, но без проводок)
6.4. Методики расширения настроечных данных, ввода остатков, распределения ролей и прав доступа, обязательные и необязаетльные типы документов.
6.5. Преднастроенные отчеты, KPI, кубы.
6.6. (в самом конце) плюс некоторый относительно небольшой объем программирования, который делает жизнь удобнее.

Возвращаясь к исходному посту

Цитата:

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

упрощает жизнь наличие отраслевого решения у внедренца бизнес-системы?

Такое отраслевое ршение действительно бы упростило жизнь как заказчика, так и внедренца.

[glibs]

Цитата:

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

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

И вы хотите сказать, что описанное выше безобразие проще считать по средней?

Не по этому ли поводу вы писали про элементарное протаскивание формулы в Эксельке?

Цитата:

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

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

Научите?

По моим наблюдениям наиболее излюбленный метод расчета себестоимости — котловой. На объективность не претендую. Плановую — да, считают попродуктово.

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

Еще есть непрерывные всякие производства, возвратные отходы, брак, кстати.

В общем, Аксапта считает ту себестоимость, которую задумали в ней считать разработчики. Она ее действительно считает (многочисленные баги не в счет). Есть у расчета преимущества по сравнению с Экселькой. Есть и недостатки. Та же производительность, невозможность получения структуры полной себестоимости в общем случае в принципе (простые случаи купи-продай с одним уровнем в логистической цепочке в качестве контраргумента прошу не приводить, если что).

Если она вам не нравится. Ну есть много вариантов. Например:
1. Не связываться с Аксаптой.
2. Связаться и смириться с тем, что есть.
3. Купить Аксапту и всю переписать. Можно тихо, можно нудно жалуясь на жизнь.
4. Можно, наверное, набить морду разработчикам или заставить Микрософт сделать "локализованную российскую себестоимость ".

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

[mazzy]

Цитата:

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

По моим наблюдениям наиболее излюбленный метод расчета себестоимости — котловой. На объективность не претендую. Плановую — да, считают попродуктово.

Излюбленный - это сильно сказано.
Это нелюбимый, но тем не менее часто используемый метод

Цитата:

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

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

Э-э-э... Что-то в этом предложении не так.
Ты про самописку говоришь или про "базовый слой"? Что такое "базовый слой" в твоем сообщении?

[mazzy]

Цитата:

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

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

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

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

[glibs]

Цитата:

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

...
Ты про самописку говоришь или про "базовый слой"? Что такое "базовый слой" в твоем сообщении?
...

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

И ниже.

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

[mazzy]

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

[Serg]

1 Конечно проще – усреднить по каждому элементу и списать пропорцию, чем выполнять расчет по каждой партии и отслеживать очень сложную структуру, какие партии ушли, а какие нет.

2. Скидываешь ОСВ по складу в Ексель после закрытия склада и добавляешь колонки (сумм.ост+сумм.прихода)/(кол-ост + кол-во прихода) получаешь среднею правильную, далее вторую колонку сумма расхода в Аксапте/кол-во расхода в Аксапте и получает среднею по Аксапте. Сравниваешь и получаешь расхождение и налоговый риск в месте с ними.

3. Glibs вы все таки путаете понятия оценки расходов с калькуляцией себестоимости. За оценку расходов отвечает закрытие склада(сначала была мгновенная, а потом согласно выбранному методу), но этот же принцип должен соблюдаться в калькуляции и за последнею отвечает другая функциональность.

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

5. Что касается directcosta и standartcost у вас то же путаница, standartcost это метод когда общехозяйственные расходы входят в структуру себестоимости и не списываются на фин.рез. С отклонением от плановой стоимости расходов он не имеет ни чего общего.

Да заказчики подсаживаются и начинают инвестировать в партнеров, а не в самих себя.

[glibs]

Цитата:

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

...
лучше не краткое содержание, а сразу ссылку на определение термина
...

Может читать дискуссию с начала перед ответом будет правильнее?

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

[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

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

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