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

Добрый день!  В управлении  персоналом ИТ  работаю 15 лет. Нынешняя тенденция  и подходы  к правилам собеседования, интервью  имеют свои вариации. Хочу поделиться одним из направлений. В моей компании  принято  проводить интервью с претендентами  по видео скайпу. Все записывается сохранять и держать на сервере. Это дает возможность подключать руководителей подразделений не  дергая их с  рабочего места.  Созданная файловая видео-аудио база претендентов  автоматически  обрабатывается и группируется по категориям ответов и вопросов, принятым решениям. Это весьма  удобная форма  проведения интервью, позволяющая   нанимать в филиалы своего офиса людей  из Англии, Франции, Канады, США. Система распознавания речи  автоматически создает анкету претендента. А онлайновая  видео запись  решения тестового  задания  претендентом  дает возможность  руководителям отделов  посмотрев запись принять решение по кандидату или претенденту на вакансию. Хотелось, что бы  такой подход  нашел в САП  свою реализацию.

Эх, да бы не быть обвиненным в плагиате :-), но уже года как полтора назад было вложено: мной:
 
----------------------
Тут типа бойцы из Panorama Consulting Group решили сравнить две системы и таки сравнили их, так что оригинал находится тут: panorama-consulting.com/erp-software-clash-of-the-titans-sap-vs-oracle , а в вольном переводе это будет звучать где-то так как я написал ниже. Сразу говорю, что перевод авторский :
 
Средние и крупные клиенты Panorama Consulting Group, задают вопросики по поводу выбора системы класса ERP, а так как на базаре только две альтернативы, то при всем богатстве выбора в основном выбираем из SAP и Oracle. Поскольку эти два решения занимают основную долю на рынке корпоративного программного обеспечения, то бойцов из Panorama Consulting Group, такие вопросы не только не удивляют, но и для них они не являются редкостью. И бойцы готовы, за соответствующую денежку, быстро ответить на такие вопросы, потому как удивительное рядом, но оно запрещено, как пел классик, а удивительное заключается в том, что системы очень разные, но если заглянуть к ним под одеяло :-), то... в общем сейчас народ из Panorama Consulting Group и опишет как там под одеялом-то.
 
Panorama Consulting Group исследовала, исследовала и таки выяснила что оказывается данные системы SAP и Oracle  EBS имеют как сильные так и слабые стороны и компромиссы (кто бы сомневался). Далее оказывается что не только системы, но и клиенты имеют разные потребности, начиная от различных функциональных требований, технической зрелости компаний и готовности идти на риски, а так же наличием бюджетов на распил при внедрении таких систем. Короче, факторов море и без бутылки, обычный рядовой клиент фиг поймет, что ему надо, потому что, между системами SAP и Oracle EBS имеются огромные различия, но и это ерунда, потому что мы, трезво мыслящие пацаны Panorama Consulting Group еще и сами вносим путаницу в выбор, часто рекомендую различным клиентам работающим в одной и той же отрасли различные решения.
 
В общем, чем же различаются данные системы? На первый взгляд всем, начиная от методики внедрения и заканчивая функциональностью решений, но на второй взгляд, есть пять основных критериев, по которым следует оценивать системы при выборе SAP или Oracle EBS.
1. Выбор между лучшей функциональностью или тесной модульной интеграцией. Стратегия этих двух поставщиков различна. SAP создавал свои решения в первую очередь с нуля, Oracle EBS в это же время занимался покупкой лучших в свое классе локальных решений, например Oracle приобрела Demantra для модуля продаж и оперативного планирования, Hyperion для финансовой отчетности, и Siebel CRM и т.д. В то время как SAP создала большую часть этой функциональности с нуля в одном, своем ERP решении.
2. Планы по развитию систем, или как любят начальники, дорожная карта развития системы. SAP в этом деле продолжает как и ранее укреплять и развивать свой ассортимент продукции, в то время как Oracle EBS движется в сторону развития своего продукта Fusion (от меня это типа звучит так: Лари Елисон в свое время озвучил, что вот дескать сейчас мы купили
команды профессионалов с их продуктами, а потом они напишут, то что и будет настоящим Oracle EBS, а то что сейчас это переходный продукты). Так вот будет этот Fusion или нет, это как говорится еще одна бабушка сказала, а это уже типа риски развития линейки Oracle EBS, а то там пацаны вот недавно Sun купили, а вдруг забьют на этот Oracle EBS и повернутся к базам данных и операционным системам с железом во главе, а тем кто купил Oracle EBS, мучайся потом, так как и выкинуть дорого и развивать его уже никто не хочет, особенно, если кто уже купил продукты D Edwards и Peoplesof, которые сейчас входят в Oracle EBS, так этим пацанам совсем может быть хорошо, если компании надоест возиться с Oracle EBS.
3. Гибкость. Так сказать вторая сторона медали тесной межмодульной интеграции SAP, потому как может оказаться, что натянуть систему на ваши как вы думаете клиентские хау ноу, будет очень сложно, хотя SAP и декларирует гибкость своей настройки. В общем виде это и сила и слабость таких систем. С одной стороны жесткая интеграция помогает соблюдать стандартизацию бизнес-процессов в масштабе всего предприятия, но с другой стороны может оказаться, что изменить функционирование системы SAP под требования клиента будет очень сложно. Oracle EBS в этом деле представляет для каждого подразделения компании лучший практический опыт, который гибко может быть подстроен под бизнес компании, но при этом сохранить общую стандартизацию процессов, в рамках крупных компаний скорее всего не будет представляться возможным.
4. Общие расходы, продолжительность и риски. В общем виде так как на базаре только два монстра, то и внедрение их будет дороже и дольше, чем других специализированных систем с функциями ERP. Oracle EBS имеет небольшое преимущество по срокам внедрения и стоимости реализации, пацаны из Panorama Consulting Group, считают, что это будет меньше в районе 20%, чем внедрение SAP. С другой стороны они же считают, что эта цифра окупается более низким бизнес риском возникновения серьезных проблем в ходе дальнейшей эксплуатации системы SAP.
5. Бизнес-преимущества и полученные удовольствия от самого процесса или так называемое послевкусие от использования :-). Тут типа SAP впереди по бизнес преимуществам, хотя Oracle EBS имет самый высокий уровень удовлетворения клиентов. Изучая внедрения по всему миру, а это порядка 1300 внедрений систем в 2008 году, таки выходит что SAP предоставляет более лучший пакет для бизнеса, т.е. все таки сильная межмодульнаня интеграция это плюс, поэтому для большинства компаний, вот того самого первого пункта 1, может быть достаточно, чтобы оправдать внедрение SAP, который может стать цементом для многих компаний.
 
Хотя между системами есть ключевые различия, они все же обладают общими чертами (а мне показалось, что как раз наоборот). Обе компании активно продают как сами системы так и последующую поддержку своих решений. Обе компании предпочитают по дольше и подороже внедярть свои решения, чем другие существующих решений класса ERP, как например Microsoft Dynamics ERP, Epicor и Infor и т.д. Обе системы являются масштабируемыми, способными вести учет согласно международных требований, они проверены временем и и работой в крупных компаниях.
 
Поэтому, как и любое решение класса ERP, SAP и Oracle EBS, оба имеют свои сильные и слабые стороны. Одно решение может наилучшим образом подходить для одной организации, в то же время в рамках другой, работающей в той же отрасли, оно может не годиться. Единственный способ разобраться это нанять пацанов из Panorama Consulting Group или других аналогичных консалтинговых компаний, которые и помогут определить и учесть ваши требования, приоритеты и конкурентные преимущества и т.д., чтобы найти подходящую для вас систему.

Все верно, в России и странах СНГ 90% проектов это внедрение ради внедрения. Бизнес и руководство не понимают ни для чего это все делается, ни как проводить оценку внедрению и понять какой эффект это имеет на бизнес.
К сожалению, большинство российских вендоров не обладают собственной экспертизой, поэтому прибегают к услугам фрилансеров, при этом ни бизнес, ни вендор не особо вдаются в подробности что там фрилансер наделает. Зачастую в такой ситуации любую даже бредовую хотелку бизнеса вендору проще молча реализовать, чем доказывать почему надо поменять бизнес-процесс.
Ситуация очень похожа на театр с плохой игрой актеров. На проектах есть заказчик, которому как бы нужно автоматизировать бизнес-процессы, как бы бизнес, который прям стонет как хочется начать работать согласно Best Practice, вендор, у которого как бы есть эксперты, которые знаю что и как автоматизировать именно в этой индустрии. А в итоге получается как всегда.

Я сторонник мнения, что в современном мире ERP превращается в базовую инфраструктурную компоненту (как водопровод, электричество, телефон, интернет и т.д.), без которой немыслимо существование современной компании,  Врядли кто-то будет считать целесообразность внедрения водопровода и электричества. То же самое относится и к ERP.
 
Кто хочет поспорить - прочитайте вначале книгу "Does IT Matter?" (Блеск и нищета информационных технологий) Николас Карр

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

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

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

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

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

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

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

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

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

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

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

5 баллов :)
)))))
"бюджетненько"

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

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

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