Комментарий:
Часто интегратора выбирают по наличию опыта проектов в том бизнесе, который ведет заказчик.  Отзывы об успешности проекта часто исходят от ПМ клиента - лица заинтересованного, а вот оценку эффекта от проекта в целом ни разу не слышал.
При этом по отдельным процессам, таким как управление запасами часто видно конкретный эффект в виде уменьшения запасов, повышения точности планирования и пр.  Однако, этот процесс - это 10-20 % системы, эффективность корпоративной отчетности ни разу не видел.
Если бы партнеры по внедрению могли демонстрировать решения по НЖЯ, у них были бы явные преимущества.

Комментарий:
Было бы очень интересно узнать мнение продавцов SAP CIS, почему клиент принял такое решение. Какие + и - у такого решения для данного конкретного клиента.

Комментарий:
Ну потому что WMS от SAP докручивать и докручивать до вменяемого состояния... так что интерфейсы оно проще иногда бывает.

Комментарий:
Не понятно, почему не внедрили СУС от SAP, раз SAP у них уже есть.

Комментарий:
Думаю дальше что-то обсуждать нет смысла так как нужны реальные примеры о том что лучше. Из моей практики лабораторные системы, проигрывают полевым, но привести примеры получится вряд ли так как по правильному нужно иметь клиента, лабораторию и понеслось.. а на выходе бы получили что вышло лучше и что лучше стало тиражироваться.
 
PS: Кстати я так и не понял, почему в вашем примере лабораторная система это стройная конструкция, а полевая это всегда некий набор костылей?! Хотя даже при таком подходе полевые костыли уже работают, а вот так стройная конструкция еще даже не догадывается какие костыли ей будут лепить в ходе внедрения :-)

Комментарий:
Путано получается, надо проще! Да и название Лабораторные/Полевые - неправильное. Все же не Полевые а Боевые.
 
Лабораторные / Боевые
 
Ассоциативно может показаться, что боевые обязательно должны быть лучше, но чтобы лучше представить я уточную параллель.
 
Допустим бизнес – это пушка, а ERP система – это конвейер для быстрой подачи снарядов (по техническим причинам снаряды лежат не совсем рядом). В этом случае вид и форма боевого конвейера зависит от рельефа местности. Но обратите внимание, что для другой пушки тот же самый конвейер может не подойти. Если мы воюем на ровной поверхности, то всегда подойдет, но даже в той же отрасли новая компания находится на другом месте и там другой рельеф.
Боевой конвейер можно переместить к другой пушке, отпилив все лишнее и укрепив дополнительными подставками, однако есть шанс, что после того как мы отпилим все лишнее выясниться, что у этой самоделки нет каркаса и она не жизнеспособна.
Лабораторный конвейер, конечно разрабатывался на ровной местности, но его сразу пытались сделать таким, чтобы и в овраге при небольшой допилке, он бы смог работать. Конечно жизнь преподнесет нам совсем другой овраг, и все конструкция лабораторного решения имеет жесткий хребет и есть шанс заставить его работать в новой местности.
 
Второй вариант анологии – это вакцина. Бизнес – живое существо, болезнь – это человеческий фактор. Боевая вакцина конечно эффективна, но только для конкретного штамма вируса. Другая фирма – это другие особенности и люди используют их иначе в свою пользу. Это тоже человеческий фактор, но он имеет другие проявления – другой штамм. Боевую вакцину исправить сложно, вот новую лабораторную, которая сразу делалась для уничтожения различных вирусов натравить на новый вирус проще…

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

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

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

Комментарий:
"Мы исходим из того, что в 2012 – 2014 году на рынке ERP систем будут «править бал» не клиенты - энтузиасты и покупатели «под IPO», а покупатели – прагматики."
 
Мда, мне бы вашу уверенность... и где бы взять этих "прагматиков"...

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

Комментарий:
А как же народная мудрость? - "в своем глазу бревна не видно"! Стоит ли требовать полный перечень проблем от Заказчика?
Конечно, они знают ради чего запускают Проект (должны знать). Но все ж, рассчитывать на полный перечень проблем не стоит, да и в любом случае, перечень может и должен быть расширен совместными усилиями Заказчика и команды внедрения - ведь кроме не заметных изнутри проблем еще существует целый набор различных траблов, которые непосредственно проявляются при интеграции всех процессов в единую систему.
 
А по "бюджетненько" - специально взял в кавычки, поскольку, не сильно верю, что проекты внедряемые слабой командой (в т.ч. и с перегруженными разными задачами специалистами) выходят действительно бюджетными.
 
Проект СО - частности, но появление там такого архитектора, как Олег - немного повышает шансы проекта на успех!

Комментарий:
Ну текущий проект СО, весь очень бюджетненько выходит, тут у нас у всех по две роли, но хотя бы так, чем вообще никак...

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

Комментарий:
Как части мы видим до начала проекта перечень проблем бизнеса, которые должен решить проект внедрения?

Комментарий:
5 баллов :)
)))))
"бюджетненько"

Комментарий:
Идеально верно! Но, на каждом ли проекте выделяется архитектор решений?
Намного чаще встречаешь ситуацию обратную, когда состав консультантов представляет собой разрозненный по направлениям коллектив. А ответственность за принятие взвешенных решений ставят на руководителя проекта. Часто, в довесок к одному из направлений, которые он непосредственно курирует.
 
В итоге - "бюджетненько"!

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

Комментарий:
Спасибо!!!
Рады знать, что мы не одни такие (мы догадывались, что не одни). И что наш проект - это не что-то немыслимое и сверхестественное, и что он может быть не только в нашей компании...
 
С наступающим Новым Годом и желаем больше интересных и позитивных событий в Новом Году!!!

Комментарий:
Т.к. все наши пользователи:
а) в пути,
б) на продукции  от Apple,
 
то только Web Intelligence.
Crystal Reports  у нас не установлен.
 
Дашборды нравятся, НО... мы их не показывали пользователям, по крайней мере в этот раз.

Комментарий:
Ваш опыт подвИг нас тоже на пОдвиг! :-) Извините за каламбур... Заканчиваем аналогичный внутренний собственный проект!

Комментарий:
пользуются :-)

Комментарий:
Хотел уточнить про отчетность - чем больше пользуется Ваши пользователи - Web Intellegence или Desktop Intellegence? Реализовывали ли отчеты в Crystal Reports? Я так понимаю для анализа результатов руководству больше нравится, наверное, дашборды Xcelsius? С Наступающим! :-) Успехов!

Комментарий:
Так ведь была подготовка к Рождеству, потом Рождество, сейчас - после Рождества построждественские скидки ))). Отчет готовим.

Комментарий:
Получается выделенный месяц прошел, результат есть, дорабатывать можно вечно? пора SAPу трубить в фанфары, что успешно показательно внедрено решение SAP BObj, почему  молчит? :-)