У меня нет.. как видишь уже прошло больше двух месяцев и где те сотни взломанных SAP-систем? Что-то не видно.. зато какой заголовок вышел, пугалка для топ-менеджера...
 
PS: А про шоколадку я тоже не передергиваю... таки известен такой случай к сожалению, как и другие, хобби знаете собирать такие истории... про "жуликов" :-)

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

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

По такой логике зачем вообще заниматься безопасностью, если все можно "узнать за шоколадку". Для полного комплекта к этому осталось добавить кому нужно ИТ, если все можно сделать на бумаге. Безусловно, все это новое слово в мировой ИТ и ИБ индустрии.

Александр вы как-то уже давно всех пугаете, пугаете, вот например такое уже было:
 
----------
Через неделю половина SAPсистем, доступных из Интернет, будут взломаны
    
4-го августа на крупнейшей  международной конференции по взлому и защите компьютерных систем – BlackHatUSA 2011, которая пройдет в Лас Вегасе,  технический директор Александр Поляков  из Российской компании DigitalSecurity покажет, как любой злоумышленник сможет получить доступ к системам под управлением SAPиз сети Интернет, используя новый класс уязвимостей.
------------
 
Как видим дата стоит 4 августа 3011 года и как видим что-то нету рвущих на себе волосы 50% IT-директоров, у которых чего-то там поломали, а уже ведь больше чем полгода прошло, а они видишь ты не поломанные стоят... статистику взломов портят. Хотя нет через пару месяцев вышло вот такое сообщение:
 
--------------
Спустя 2 месяца с момента публикации доклада о критической уязвимости в J2EE движке SAP, не все смогли оценить ее критичность, несмотря на то, что данная уязвимость представляет крайне серьезную угрозу безопасности SAP. Это указывает на то, что напрямую ей подвержены только системы на основе JAVA, которые зачастую не хранят критичные данные как, например, ERP или BI, а используются для связи этих систем.
---------------
 
Короче все могут спать пока спокойно... потому что похоже особо никому эти уязвимости не мешают, потому что за шоколадку кому надо, можно и так получить больше, чем еще что-то где-то как-то ломать и не переломать :-)

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

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

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

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

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