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

[mazzy]

Цитата:

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

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

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

[mazzy]

Ой. Извините, BOAL.
Я не обновил загруженную страницу перед своим ответом.

[Андре]

Решил и я вмешаться в разговор

Цитата:

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

По поводу часто звучавшей здесь фразы "не надо программировать".

Ок. Допустим клиент старается не модифицировать приложение. Что он при этом получает:

+ Он легко переходит на новую версию приложения

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

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

ERP-система это не Windows, чтобы каждый год переходить на новую версию. Просто потому, что это модно.

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

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

[BOAL]

Андре написал очень верно!
Действительно, раз Вы даже не видели систему, но уже готовы вклыдывать деньги, то резонно спросить " А у Вас есть ответ - зачем это Вам?"

Лично мне нужны были от 3.0 новые книги покупок и продаж, налоговый учет и тп (да просто за время с 25сп2хф1 до ах30 было 7 обновлений , то есть явно много нового для меня).
Плюс реструктуризация учета бизнес процессов, тк за 2 года было сделано много "лишнего" и все подчистилось и работает на новом уровне.
Но если у Вас все ок и так, то может просто распотрошить код и взять нужное?

Тем более у Вас буржийская система и, как я понимаю, многое от локализации российского бизнеса Вам попросту не нужно.

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

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

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

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

[EVGL]

Цитата:

Меня интересует, как можно осуществить переход а) быстро б) дешево в) без потерь и простоев.

Ну вы же знаете все ответы, но продолжаете дискуссию.[list=a][*]Быстро - за счет качества, т.е. отказа от оптимизиции кода и/или тестирования;[*]Дешево - за счет времени, т.е. опять качества, и следования советам методических рекомендиций MSBS;[*]Удачно - благодаря тестированию и следованию методичкам.[/list=a]
Нет никаких волшебных секретов, нет искуственного интеллекта, который сделает за вас работу, пора ее начинать, если есть уверенность в том, что ее вообще надо начинать.

Для того чтобы проверить, не завышают ли поставщики время на обновление кода, используйте формулу кол-во часов = кол-во затронутых элементов / 4. Это - верхняя граница. На тестирование отводите от 30 до 50% времени, ушедшего на подъем кода.

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

EVGL,

За формулу - спасибо, буду еще больше благодарен, если объясните, откуда взялась цифра 4...

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

В конце концов, я считаю - есть конкуренция между Аксапта-внедрятелями, и она нам поможет

[EVGL]

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

Конкуренция - да, но не все партнеры, очевидно, делают работу одинаково хорошо.

[gnad]

Цитата:

Изначально опубликовано EVGL
Для того чтобы проверить, не завышают ли поставщики время на обновление кода, используйте формулу кол-во часов = кол-во затронутых элементов / 4. Это - верхняя граница. На тестирование отводите от 30 до 50% времени, ушедшего на подъем кода. [/B]

Интересная формула (две таблицы + две формы / 4 = 1час), она войдет в очередной пресс-релиз? Для локализации базовой функциональности скорее да, чем нет. Для переноса серьезных клиентских модификаций ну оччень оптимистично.

[EVGL]

Не надо понимать меня превратно. Я разве написал "две таблицы и две формы"? Я написал "элемента". Читай - любого. Например: 1 расширенный тип + 1 таблица + 1 пункт меню + 1 класс за час. Притом с обязательным первичным тестированием самим программистом.

Второй вопрос: при чем тут пресс-релиз? Чей? Это - моя субъективная оценка для больших проектов, в которых в равной степени встречаются как косметические модификации форм, так и глубокие изменения в коде целого ряда модулей.

Приведите свои выкладки, я могу привести свою статистику. Да, статистика основана на "подъеме" всей локальной версии Аксапты, но недавно пришлось заниматься клиентскими проектами. На них времени уходило в среднем (на один элемент) процентов на 25 меньше, поэтому и написал: "верхняя граница".

Если подъем какого-либо проекта занимает больше времени, то это должно быть очень серьезно обосновано. Например: 60% изменений - это серьезные переделки сводного планирования со всеми вытекающими. Или: есть web-приложение, которое теперь надо разработать заново. Или: код написан настолько плохо, что модификации NN. 1, 5, 7 лучше полностью переписать, на что уйдет X часов.

Все остальное - от лукавого (читай - снять с клиента побольше денег).

[mazzy]

Цитата:

Изначально опубликовано EVGL
Все остальное - от лукавого (читай - снять с клиента побольше денег).

Как только в утверждении появляется слово "все" жди логических ошибок...

Есть еще один случай непростого перехода: переход с Ах2.5SP2 CIS на Ах3.0

Согласен с тем, что в общем случае очень сложно сказать более-менее вменяемую оценку. Тем более "навскидку".

Продолжаю настаивать на оценке - стоимость подъема сопоставима со стоимостью доработки.

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

Например, руководитель проекта говорит, что поднять на новую версию будет "раз плюнуть". То же самое он говорил о доработках. Известно, что бюджет времени по доработкам превышен, например, в три раза. Значит бюджет подъема на новую версию, объявленный этим руководителем, надо увеличивать в эти же три раза.

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

Навскидку можно дать только такую оценку. Точнее не получится.

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

[EVGL]

Цитата:

Изначально опубликовано mazzy
Продолжаю настаивать на оценке - стоимость подъема сопоставима со стоимостью доработки.

Вопрос в коэффициенте. Если вы утверждаете, что коэффициент = 1.0, то я не согласен: считать, что на подъем уходит столько же, сколько на разработку, это просто устрашающий пессимизм. Тогда версию 3.0 CIS мы увидели бы где-то к началу 2004 года.

Цитата:

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

Истина. Хотя руководители - тоже люди и иногда учатся на своих ошибках.

Цитата:

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

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

На моей практике погрешность примерно такая: -20%...+30%. Тут, правда, надо учитывать то, что все программисты всегда были примерно одного - весьма высокого - уровня. И еще то, что любая работа стремится занять все отведенное ей время Сама оценка времени - это серьезный фактор, влияющий на время разработки.

[EVGL]

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

[mazzy]

Пусть так. Время покажет.

Кстати, насчет начала 2004 года - мысль интересная. Надо подумать.

[gnad]

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

[BOAL]

Про перенос данных (и исторических данных по модулю кассы из ранних версий ах25)
Кассу перенести удалось в новый формат и постоить по ней книгу уже в новой аксапте, получить сальдо по сотруднику в АО и тп....

Я столкнулся с тем, что у меня жувут 4 компании в БД и переносить пришлось поштучно, применяя кучу своих обработок...
При этом компании переносились в начале для тестирования ах30 на живых данных, а потом как "переезд" (т.е. минимум 8 раз переносились данные)
Итог таков - компания пееезжает за 1ч +время, зависящие от мошности копма, на котором идет выполнение обработок. в моем случае это 2-4ч на компанию.
Обладателей милионов записей в InventTrans будут иметь цифру соизмеримую с сутками (у меня складских проводок 20тысяч по одной номенклатуре максимально и таких номенклатур не так много)

Так что перенос данных за Х часов реальность, если есть методики..
А вот сколько я эти методики разрабатывал - второй вопрос
Но зато теперь могу как выездной цирк переносить данные из ах25сп2хф1 в ах30
(из аз25сп2 (без хф1) переезд осложнен не совместимостью корреспонденции в главной книге)

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

Замечу что насколько удачно перенеслись данные станет ясно только в процессе "живой работы", причем оптимально - после закрытия первого периода.
И что перед переносом данных надо произвести перенос все программной логики, а именно это и займет непредсказуемой время, если было много кастомизаций.
Принятие решения о внесении изменений в стандартный функционал - отвественный шаг. Если можно лечить что-то "терапевтически", то "операций" надо избегать.
Нормальное документирование разработок, по моему опыту, занимает не менее 20% времени. Если это время не затрачено на этапе разработок, его будет вдвойне больше затрачено на этапе сопровождения. Другое дело, что там время будет идти уже "в текущем режиме", то есть как бы не заметно. Но суть от этого не меняется.
Переход к новой версии я бы совместила с пересмотром внесенных модификаций и частичного отказа от собственных разработок в пользу стандартного функционала.

[Megacrusher]

to Михал Семенов:
Михаил могу обобщить высказывания предыдущих Участников. Сам много раз переводил и участвовал в переводах сервис-паков и на трешку тоже уже переводил.
Для того чтобы Вам более-менее точно сказать сколько займет перевод Вам нужно.
1) Сказать сколько элементов изменено или назовите количество мб файла слоя (где лежат изменения)
2) Сколько часов было затрачено на модификации (приближенно) Сколько людей было задействованно.
3) Были ли документированы изменения

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

[Pavel]

Цитата:

Изначально опубликовано Megacrusher
А вот насчет быстроты и дешевизны есть другая универсальная формула «Быстро, качественно, дешево – выберите любые два компонента». И вы сами поймете где у вас будет пробел...

Поддерживаю, это классика консалтинговых проектов, каждый из факторов действует против остальных.

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

Цитата:

to Михал Семенов:
Михаил могу обобщить высказывания предыдущих Участников. Сам много раз переводил и участвовал в переводах сервис-паков и на трешку тоже уже переводил.
Для того чтобы Вам более-менее точно сказать сколько займет перевод Вам нужно.
1) Сказать сколько элементов изменено или назовите количество мб файла слоя (где лежат изменения)
2) Сколько часов было затрачено на модификации (приближенно) Сколько людей было задействованно.
3) Были ли документированы изменения

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

Спасибо за реальные советы.

Отвечаю...
1. Файл axusr.aod - 11 Mб. axvar.aod - 12Мб. axbus.aod (и там тоже наследили!) - 1.5 Мб.
Представляю, что вы после этого про нас подумаете
2. Задействовано было: 1 человек постоянно, плюс от двух до 5 аккордно. В целом я бы оценил все доработки грубо в 1000 - 1500 программистских человеко-часов. БОльшая часть из них пришлась на этап внедрения, процентов двадцать тридцать - после.
3. Документации нет. Совсем. Так получилось