Cпец.условия MS при миграции с NAV на AX

[sanya_123]

Уважаемые коллеги!

Возможно, что в ближайшем будущем мы будем мигрировать с NAV на AX.
Подскажите пожалуйста, какие специальные условия по скидкам, зачету лицензий и прочим ништякам предлагает в таких ситуациях Microsoft?
Удавалось ли кому-нибудь конвертнуть например пользователей?

у меня - более 1000 пользовательских лицензий NAV.

[Sancho]

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

[Dzemon]

Ништяки у Микрософта персонально-приватно выбиваются.

PS. Запасаемся попкорном

[sanya_123]

Цитата:

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

Цитата:

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

у меня - более 1000 пользовательских лицензий NAV.

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

А пользователи? Матерые всякие бухгалтера в возрасте, которые только-только насобачились жамкать на кнопки, отличные от 1С?

Серьёзно и интересно.
Такое кол-во юзеров с Навика, думаю, мало кто еще переводил. (разве тока Абибас)
Это же бесценный опыт!

1. Нет, увольнений не будет. Будем переучиваться.
2. Пользователей тоже переучим. Сомнений никаких, я свою собаку научил перец есть и сейчас ей это нравится.
3. Да, проект крупный. было бы не интересно- свалил бы обратно в SAP.

А вот тебя, jopa*3, я бы на работу не взял. ты, конечно, прикольный. но злой какой-то

[artkashin]

Если не секрет, почему решили мигрировать, и почему AX?
Проект перехода.. это же миллионов от 40-ка только лицензии .. для тысячи лицензий. Клоунсалтинг этак еще в 60-70 миллионов обойдется (И это, я наверное, еще приуменьшаю). И железо обновлять, под проект. Аксаптушка, особенно 2012 R3 и далее - прожорливая, аж жуть берет.
В общем, я так прикинул стоимость проекта, и задался вопросом: неужели Навик настолько плох, а Аксапта - настолько хороша?

P.S. В одном уверен точно - рынок кукурузы в этом году ожидает рост - пойду тоже прикуплю попкорна)

[Yoil]

Дык ведь помирает нав, как неоднократно тут ванговалось. На дворе уже 15-й год, а все ещё не анонсирован ни нав17, ни 18...

[artkashin]

Цитата:

Сообщение от Дуд

Дык ведь помирает нав, как неоднократно тут ванговалось. На дворе уже 15-й год, а все ещё не анонсирован ни нав17, ни 18...

Одно дело новые проекты - для них нав умер. Внедрение Нового NAV прилично дороже и гораздо более рискованное, чем у конкурентов - поэтому и 0-вые продажи.
Другое дело - уже существующая компания, где НАВ уже тесно вплетен в процессы. Вот уж ни за что не поверю, что система, разросшаяся до 1000 клиентских лицензий, перестала устраивать так, что просто требуется многолетний, болезненный и многомиллионный проект перехода...

[Yoil]

Цитата:

Меня забраковали, когда я пробовал устроиться к вам аналитиком />

[sanya_123]

Коллеги!
А вы не могли бы скинуть

"Microsoft Dynamics Licensing Transition Policy"

https://mbs.microsoft.com/partnersou...md_transitions


по поводу
.....Угадал! Меня забраковали, когда я пробовал устроиться к вам аналитиком
Хотел вместе с остальной сотней тысяч планктона ходить через вертушки в галстучке и рубашечке.
Деееевочки ухоженные в колготах... Маааальчики сытые с гаджетами... И все на позитиве. Эххх-x ....

Сергей который jopa*3, видишь - не я один так думаю.
вывод какой- внутри можешь быть каким угодно, но палиться нельзя.

[asm_imported]

С причиной перехода все просто. С 2017 года все страховые компании переходят на новый план счетов и будут вести учет по правилам ЦБ. К этим правилам НАВ совсем не приспособлен, по-крайней мере я о внедрении НАВ в банке не слышал. Вот и побежали все кто-куда, кто в 1С, кто в АБС, а кто и в Аксапту. Правда не понятно чем в этом смылсе Аксапта лучше НАВ, в банках она тоже не распространена.

[artkashin]

Цитата:

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

С причиной перехода все просто. С 2017 года все страховые компании переходят на новый план счетов и будут вести учет по правилам ЦБ.

а что, отложили на год переход? я слышал, что вроде со следующего года переход.

Цитата:

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

К этим правилам НАВ совсем не приспособлен, по-крайней мере я о внедрении НАВ в банке не слышал. Вот и побежали все кто-куда, кто в 1С, кто в АБС, а кто и в Аксапту. Правда не понятно чем в этом смылсе Аксапта лучше НАВ, в банках она тоже не распространена.

поэтому я и задал вопрос, Если уходят с NAV, то почему именно AX? это именно, что двойная засада. И новый продукт, и нет понимания того, как это должно работать - причем ни у кого.

[asm_imported]

Цитата:

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

а что, отложили на год переход? я слышал, что вроде со следующего года переход.

Дык еще в феврале ЦБ все сроки сдвинул. Вот ссылка
Тк с 2106 начать было нереально.

Цитата:

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

Если уходят с NAV, то почему именно AX? это именно, что двойная засада. И новый продукт, и нет понимания того, как это должно работать - причем ни у кого.

Может у консалтера как раз есть опыт внедрения Аксапты для кредитных организаций.

[artkashin]

Цитата:

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

Дык еще в феврале ЦБ все сроки сдвинул.
Тк с 2106 начать было нереально.

)) классная опечатка)

Цитата:

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

Может у консалтера как раз есть опыт внедрения Аксапты для кредитных организаций.

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

Но ведь тоже самое можно и на NAV сделать)

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

[Yoil]

Артем, вопрос:
1) Переделываем текущий Нав под вот этот новый план
2) Внедряем другой продукт под вот этот новый план
Для упрощения считаем, что человекочас стоит одинаково

Насколько сравнима стоимость обновления лицензии под новый продукт со стоимостью всей переделки/внедрения нового продукта?
Усложняем задачу: В "старом" продукте наверняка есть кривые решения, которые живут годами, но до них не доходят руки, т.к. важней удовлетворить бизнес в плане реализации новых задач.

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

[Sancho]

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

---
Усложняем задачу: В "старом" продукте наверняка есть кривые решения, которые живут годами, но до них не доходят руки, т.к. важней удовлетворить бизнес в плане реализации новых задач.
---
и еще усложним задачу, "старые" решения, какими бы кривыми они не были, РАБОТАЮТ. и назначение свое выполняют и пользователи к ним привыкли.
и вполне допустимо, процентов на 60, что кривые решения были написаны специально под кривые бизнес процессы.
а теперь возьмем новую систему, кривые процессы и попробуем быстренько на коленочке нарисовать решение... впереди еще год-полтора вылавливания кривизны решения... которое может получиться не сильно "прямее" предыдущего...

[artkashin]

Цитата:

Сообщение от Дуд

Усложняем задачу: В "старом" продукте наверняка есть кривые решения, которые живут годами, но до них не доходят руки, т.к. важней удовлетворить бизнес в плане реализации новых задач.

Беда в том, что в новом продукте может не оказаться даже кривого решения). А на этапе дизайна новой системы, о задаче, имеющей в текущей системе кривое решение успешно забудут)
В общем, Sancho написал лучше и точнее.

Цитата:

Сообщение от Дуд

Артем, вопрос:
1) Переделываем текущий Нав под вот этот новый план
2) Внедряем другой продукт под вот этот новый план
Для упрощения считаем, что человекочас стоит одинаково

Насколько сравнима стоимость обновления лицензии под новый продукт со стоимостью всей переделки/внедрения нового продукта?

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

Вот попытаюсь построить план проекта по переделке NAV на новый план:
1) Анализ.
1.1) собрать данные о требованиях к новому плану.
1.2) Создать учетную политику компании по ведению учета "в новом плане счетов".
1.3) собрать данные о текущем поведении системы в части затронутых на этапе 1.2 изменений.
1.4) Провести Gap & Fit.
2) Дизайн
2.1) выбор двух вариантов из классического треугольника "быстро, дешево, качественно").
3) реализация
4) тестирование и интеграционное тестирование, тестовая эксплуатация
5) обучение
6) ввод в эксплуатацию

И так. Пункт 1) самый интересный.
1.1) Кто об этом знает в компании? Скорее всего, никто. Приглашаем консультантов. Но не консультантов по текущей системе, а бизнес-консультантов - Big Four, Эрнтс энд Янг, какой-нить)
1.2) Аналогично - это разработка учетной политики бизнес-консультантами.
1.3) Вот тут взаимодействие бизнес-консультантов с консультантами/разработчиками текущей системы.
1.4) Аналогично, бизнес-консультанты ставят задачи консультантам по системе с целью выявления Gap. С одной стороны - понимание того, что требуется, с другой - понимание, что есть, и готовность это продемонстрировать "на лету".
2) Дизайн пишет по большей части консультант-по системе, принимает бизнес-консультант.

И так.. что же в этом подходе интересного? а то, что причем тут текущая система? Решение о замене текущей системы надо принимать после 1.4) а то и после 2) а до этого, должны поработать Бизнес-Консультанты. И все последовательно. Процессы - контролируемые. Неизвестная переменная - она одна - и решение этой неизвестной переменной лежит в плоскости, далекой от системы.
4) тестирование может быть по сути проведено максимально быстро, на существующих рабочих данных - фидбек будет получен моментально и можно даже поэкспериментировать с тестовой эксплуатацией задолго до.
5) обучать скорее всего не очень то и понадобится.

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

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

Т.е. проект даже на этапе анализа сквозь "розовые" очки - пахнет неопределенностями)
Это при условии отсутствия демаршей и политического саботажа среди разного уровня политиков в столь крупной компании, как РГС - а он будет.
Можно ли такой проект запустить за полтора года? Наверное можно. Но можно и не запустить).

Анекдот в тему:
Плывут Василий Иванович и Петька через Волгу.
проплыли Четверть пути:
-Василий Иванович, я больше не могу.
-Терпи Петька, терпи.
проплыли половину:
-Василий Иванович, я больше не могу.
-Терпи Петька, терпи.
Проплыли три четверти.
-Василий Иванович, я больше не могу.
-Терпи Петька, терпи.
Проплыли почти уже весь путь. До берега чуть-чуть.
-Василий Иванович, я больше не могу.
-Ну поплыли обратно.

[sanya_123]

попытаюсь ответить на несколько вопросов...

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

беда в том, что по сути возникает некий гибридный вид учета, в мире нет ничего подобного, в России может быть кто-то что-то напишет, но сейчас пока мало что есть.
+/- окончательные требования ЦБ слил где-то 01.04.2015.

1. почему не NAV ? - потому что по новым требованиям мне нужно будет вести детализированный учет продаж страховых продуктов, а это порядка 300 000 000 проводок в год. ну или всего 1 000 000 в день.
2. почему не 1С ? - см выше, и не надо рассказывать что оно потянет.
3. почему не автоматизированная банковская система? - ну этот вариант мы не исключаем, но стоит оно слишком хорошо. + будешь платить за каждый чих.

ну и как бы остается AXAPTA. SAP - не рассматриваем, т.к. то же самое, что в axapta мы получим за гораздо большие деньги.

4. проект будет тяжелейшим. в любом случае
5. успехи большой четверки (которые по своей природе не MC а аудиторы) по сабж не впечатлили.
вообще, после 18 лет проектов есть ощущение, что реальные консультанты это ВНУТРЕННЯЯ КОМАНДА + любой IT консалтер на первое время.
ну и если у вас очень много денег можно поработать с маккинси, бэин и бкг. . Практического результата от остальных "MC" нет никакого!

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


-===
да, по сути вопроса. если я правильно понял, MS стандартно дает зачет стоимости лицензии при переходе с одного продукта на другой. это можно делать не чаще чем раз в 2 года и т д.
документ про переход, кстати, можно найти в свободном доступе. в TOR.

ну а мне его выслали. за что большое спасибо не скажу кому!

[asm_imported]

Цитата:

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

1. почему не NAV ? - потому что по новым требованиям мне нужно будет вести детализированный учет продаж страховых продуктов, а это порядка 300 000 000 проводок в год. ну или всего 1 000 000 в день.

А есть уверенность, что AX потянет такой объем? NAV последней версии по архитектуре очень напоминает AX. Если не брать в расчет рассказы маркетологов, что NAV для маленьких компаний, а AX для больших, то в чем технологическое преимущестов AX? Почему AX может обработать 1 млн проводок в день, а NAV не может.

[alexb_imported]

Цитата:

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

Цитата:

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

1. почему не NAV ? - потому что по новым требованиям мне нужно будет вести детализированный учет продаж страховых продуктов, а это порядка 300 000 000 проводок в год. ну или всего 1 000 000 в день.

А есть уверенность, что AX потянет такой объем? NAV последней версии по архитектуре очень напоминает AX. Если не брать в расчет рассказы маркетологов, что NAV для маленьких компаний, а AX для больших, то в чем технологическое преимущестов AX? Почему AX может обработать 1 млн проводок в день, а NAV не может.

А можно поподробнее? Признаюсь, я ещё ни разу не видел Аксапту, даже демо, всю дорогу вожусь с НАВ и всю дорогу всегда слышал что у Аксапты другая архитектура, которя больше подходит крупным фирмам с большими базами данных. В чём конкретно в этом смысле скачок у NAV2015?

[artkashin]

Цитата:

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

Цитата:

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

1. почему не NAV ? - потому что по новым требованиям мне нужно будет вести детализированный учет продаж страховых продуктов, а это порядка 300 000 000 проводок в год. ну или всего 1 000 000 в день.

А есть уверенность, что AX потянет такой объем? NAV последней версии по архитектуре очень напоминает AX. Если не брать в расчет рассказы маркетологов, что NAV для маленьких компаний, а AX для больших, то в чем технологическое преимущестов AX? Почему AX может обработать 1 млн проводок в день, а NAV не может.

Ну.. идеологии AOS и ее балансированию много лет - а также большая наработанная практика.
А вот насчет возможностей и маштабируемости NAV Service Tier - у меня, вообще, большие сомнения. Буду рад, если кто-нибудь меня разубедит. Есть где-нибудь нагрузочные тесты? Что будет, если на NAV Application Server подключится 1000 пользователей, да в одну фирму?

Как раз новым технологиям в NAV, с точки зрения производительности и маштабируемости я бы не доверял, от слова совсем.
За классический клиент как раз у меня меньше переживаний - там нет третьего слабого звена в виде "NAV Service Tier".

А насчет постить 1 000 000 проводок в день.. это конечно много. Стандарт напряжется).
С другой стороны, в моей практике 2 миллиона проводок в месяц есть в одной фирме (и там даже ночью не работают, постят в Рабочее время) и без какой-либо оптимизации. На хорошем железе (SSD Винты, много много памяти, и низкий пинг (а идеально прямо на сервере) от клиента нав до SQL), миллион проводок в день делать можно, даже в одной фирме.