Стоимость перехода Axapta 2.5->3.0 - как оценить?

[Михал Семенов]

Примерно полтора года работаем с Аксаптой 2.5. Запущены модули Закупки-Продажи, Склад, Клиенты-Поставщики, Главная Книга, BOM, Производственные Заказы. Хотим перейти на версию 3.0. Вопрос - как оценить, сколько это будет стоить (я имею в виду собственно перевод софта, без учета стоимости лицензий) ? Нам, разумеется, предложили стандартный вариант: взять все коды (имеется совершенно невообразимое количество доработок, сделанных разными людьми, без документации), проанализировать их, написать кол-во часов на перевод, посуммировать. Это все будет делать сторонняя компания. Мне хочется их проверить - вопрос "как"? Понятно, что ребята напишут от души, с запасом - не поверять же за ними каждый пункт...

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

Заранее спасибо,

Михаил Семенов.

[mazzy]

навскидку - сопоставимо со стоимостью существующих наработок

[Pavel]

Цитата:

Изначально опубликовано Михал Семенов
Нам, разумеется, предложили стандартный вариант: взять все коды (имеется совершенно невообразимое количество доработок, сделанных разными людьми, без документации), проанализировать их, написать кол-во часов на перевод, посуммировать.

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

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

[Михал Семенов]

Спасибо за ответы.


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

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

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

[Pavel]

Цитата:

Изначально опубликовано Михал Семенов
...хочу понимать, как они сами ее решают, насколько так сказать правильно.

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

Цитата:

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

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

Цитата:

Изначально опубликовано Михал Семенов
Должен быть более быстрый и менее трудоемкий способ сделать то же самое.

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

Цитата:

Изначально опубликовано Михал Семенов
Легкость в миграции всегда подавалась как одно из главных преимуществ Аксапты, ее конек.

Вас обманули. Такова работа маркетологов - сочинять сказки для взрослых людей. Система действительно упрощает обновление версий по сравнению с другими продуктами, но упростить решение задачи и гарантировать отсутствие проблемы обновления - совсем РАЗНЫЕ вещи.
Почитайте форум, первая полезная рекомендация будет состоять в том, что не нужно ПРОГРАММИРОВАТЬ, т.е. модифицировать продукт.

Цитата:

Изначально опубликовано Михал Семенов
Я бы сильно удивился, если вдруг выяснится, что никаких других методов, кроме тупого перелопачивания десятков мегабайт кода - нету.

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

[Михал Семенов]

Здравствуйте еще раз.

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

Я так полагаю, если руководство наше услышит диагноз именно в таком виде - то в лучшем случае оно пошлет нас подальше, и прикажет оставаться на 2.5. А в худшем - весь отдел АСУ после работы будет заниматься "анализом" до потери сознания Забесплатно, естественно...

Неужто нет других выходов??????

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

[Pavel]

Извините, Михаил, не имел цели вас растраивать.

Цитата:

Изначально опубликовано Михал Семенов
Неужто нет других выходов??????

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

[komar]

Цитата:

Изначально опубликовано Михал Семенов

Неужто нет других выходов??????

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

Каких других? Чудес-то не бывает. Если 2 человека одновременно исправляют один текст, всегда нужен третий, который будет решать, что же останется в финальной версии. Неужели Вы и правда надеялись, что система все сделает за Вас по "большой красной кнопке"? Как она узнает, что ей делать? Как это в принципе возможно? И обрадуетесь ли Вы результату?
Можно, однако облегчить себе задачу. Можно максимально использовать стандартные классы, не модифицируя их...можно писать что-то совершенно не зависящее от стандартной системы....можно по-человечески документировать программный код...но это тоже не означает ОТСУТСТВИЯ проблемы. Павел прав, чудес не бывает....

[Елена Сысовская]

Цитата:

Изначально опубликовано Pavel

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

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

[Dmitryus]

Одна из компаний в данный момент заканчивает переход на 3.0
Анализ и перенос модификаций занял 4 месяца + 1 месяц тестирования
при том что клиентских модификаций не было - просто 2.5 внедрялась одной фирмой а переход на 3.0 делала другая

[komar]

А вот и пример плохого документирования и разработки по принципу "после нас хоть потоп".

[komar]

Цитата:

Изначально опубликовано Елена Сысовская


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

А вот мнение "от клиента"
http://www.axforum.info/forums/showt...0146#post20146
покупка акзапты как средства разработки вещь достаточно часто встречающаяся...к сожалению.....

[Елена Сысовская]

Цитата:

Изначально опубликовано komar
А вот и пример плохого документирования и разработки по принципу "после нас хоть потоп".

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

[BOAL]

Я перевел систему 25сп2хф1 на ах30, а теперь уже и ах30сп1
Проблем было много, тк версия обживалась с 2001г и притерпела множество изменений.
Основные проблемы и их решение легли на пересмотр ведения бизнес процессов в системе. А имено уход от модификаций, там где это возможно, на чистую систему.
Дело в том, что большинство (ну пусть не большинство ) проектных модификаций делается для удобства (привычки) пользователей... так как на чачальном этапе работы с системой пользователи страдают определенными трудностями в "понимании" логики системы.
Очевидно, после нескольких лет работы стало возможным передти на ахапту, а не на конструктор сделай сам.
И автоматизировать бизнес процессы фирмы уже в логике системы, дописав (перенеся) только необходимое.
Стоит так же отметить, что весь блок модификаций, например, в модуле кассы (а там было очень много всего сделано) переносить не пришлось, тк ах25сп2 и ах30 не совместимы в логике работы модуля кассы... (те делать с нуля)
А вот все исторические данные в ах30 нужно было оживить, что и было проделано.

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

Ну а тестировать перенесенные модификации - это вообще песня

Так что утверждение "возмите, скажем, 20% от времени изготовления модифы на ее перенос" не верно (ИМХО) - тут смотря какая модифа... а то и х3 ко времени будет, а еще и тестировать.
Тем более сразу скажу, все изменения связанные с разноской в ГК в ах30 придеться писать заново или время будет точно >= времени создания

[Михал Семенов]

Здравствуйте все,

Спасибо еще раз всем откликнувшимся!!!! Ваши замечания - очень ценнЫ для меня.

Мне кажется, надо объяснить, какого рода "исправления" вносились в систему.
Я их делю на четыре класса.

1. Изменения в бизнес-логике. Таковых на самом деле очень-очень мало, буквально единичные. В основном мы пользуемся стандартной бизнес-логикой международной Аксапты 2.5 со вторым сервис-паком (компания наша - представительство буржуев в России).

2. Изменения в стандартном порядке сортировки-группировки запросов к БД в формах и отчетах. Например, при резервировании товаров нам нужно было сортировать по сроку годности партии, а не по дате поступления на склад. Никакими другими способами, кроме внесения изменений в класс, к сожалению, это не лечилось. Таковых примерно процентов 30 от общего объема изменений.
3. Добавления новых колонок в отчеты и экранные формы, изменения дизайна отчетов. Самое большое количество, больше половины точно. Это, как мне кажется, самое слабое место в Аксапте. Очевидно, что разным предприятиям нужна разная информация на экране. Часто из связанных таблиц, иногда вычисляемая по сложным алгоритмам. Например, нашему финотделу нужно видеть в списке транзакций по клиентам - количество дней с момента выставления инвойса до момента его оплаты. А отделу закупок - т.н. "остаток на складе в днях", т.е. на сколько дней хватит того, что сейчас есть на складе, при среднем потреблении, вычисленном на основе истории за предыдущие n месяцев. И это лишь самые простые из доработок. Мне до сих пор не понятно, почему такая развитая в общем система не имеет механизмов добавления таких полей - без изменения кода. Я уж не говорю про случаи, когда скажем в журнале складских перемещений надо выводить название каждой номенклатуры, а соответствующей таблице такого поля нету. Тут уж вообще дурдом - приходится вешать метод на таблицу, и выдавать его значение в грид, иначе просто никак... А если нужно еще и сортировку организовать по этому новому полю - это вообще труба, либо соответствующий метод перекрывай через ж., либо добавляй целое поле и инициализируй его... Ну скажите, неужели разработчикам было неведомо, что операторы просто не могут работать только с кодами материалов???? Должны были придумать что-нибудь, чтобы можно было выводить U]любое[/U] поле из связанной таблицы простой настройкой формы непосредственно в Аксапте. Такие фичи есть во многих системах...

4. Совершенно новые разработки, не меняющие стандартный код - все остальное, процентов 15 от общего объема кода.

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

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

[SnowMan]

Теперь понятно, откуда берется утверждение "не надо программировать"... из горького опыта по сопровождению...

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

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


p.s. читая эту тему, почему то вспомнился анекдот:

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

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

[BOAL]

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

Перенос фенечек в формы - это точно не сложная поцедура

[Михал Семенов]

Цитата:

Ахапта30 предоставляет очень хорошие возможности по настройке интерфейсов форм непосредственно самим пользователем

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

В конце концов, такая простая вещь как "сумма значений в фильтре" - сделали ли уже это в третьей версии, или опять придется мучиться с переносом в Excel и суммировать там? У нас очень на многих формах сумма считается автоматом, причем не просто по фильтру в целом, но и по выделенным (отмеченным самим юзером) транзакциям.

[BOAL]

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

До перехода на ах30 обязательно его посмотрите и изучите, иначе может быть накладочка
Попросите демо версию у поставщика и принимайте решение предметно, а не
"Ой, все говорят ах30 это гут!"

[Михал Семенов]

Цитата:

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

Хороший совет! На самом деле, серьезно... Одна беда. Если смотреть "голую трешку", без наших доработок - то принимать решение придется мне одному, как ответственному со стороны ИТ. Потому как пользователи будут возражать - в старой версии здесь было так, а теперь эдак, и нам неудобно. И убеждать их, что мы все перенесем и будет как раньше, только в пять раз лучше - бесполезно. Им, пользователям, ведь по барабану - версию мы меняем, или новую систему ставим. Они (совершенно справедливо!) сравнивают только "как было" с "как будет". И любое несоответствие - по любой причине - вынуждает их возражать.

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

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