Показать сообщение отдельно
Старый 13.04.2015, 20:07   #16  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от Дуд Посмотреть сообщение
Усложняем задачу: В "старом" продукте наверняка есть кривые решения, которые живут годами, но до них не доходят руки, т.к. важней удовлетворить бизнес в плане реализации новых задач.
Беда в том, что в новом продукте может не оказаться даже кривого решения). А на этапе дизайна новой системы, о задаче, имеющей в текущей системе кривое решение успешно забудут)
В общем, 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) обучать скорее всего не очень то и понадобится.

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

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

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

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