Давай попробуем вспомнить примерную проблематику острых дискуссий за последнее время:
1. Dynamics Consulting - как он будет работать с партнерами. Будет ли он внедрять систему или только будет проводить аудит качества.
2. Вопрос методологии. Существующая бесполезна на внедрении и не позволяет контролировать качество внедрений. Кстати - хорошо бы еще понять будет ли его хоть кто-то контроллировать - или все будет отданно "стихии свободного рынка"
3. Будет ли Dynamics развиваться как платформа для отраслевых решений партнеров, или как самостоятельная ERP-система годная к внедрению без существенных доработок
4. Будет ли разработана принципиально новая система - преемник Project Green. Рассуждения по поводу 2ой волны несут мало конкретики
5. Будет ли построена сколько-нибудь прозрачная система сбора и одобрения wishlist с партнеров и клиентов.
6. Как будут разведены решения по industry builder и обычные вертикальные решения. Как будет построено внедрение, поддержка и продажи этих самых решений
ну и тп
Если бы Наделла был варягом, которого только вчера поставили на новую должность, я бы понял если бы он не мог сказать ничего конкретного по вот этим вот любопытным темам. Но хотя он и проработал в подразделении MBS несколько лет - ничего конкретного он сказать не смог - только общие слова про ролевой интерфейс и тп
Теперь некоторое лирическое отступление: В начале 90ых я несколько раз сталкивался с ситуацией, при которой бывшие советские системщики и разработчики компиляторов вдруг сталкивались с ситуацией, при которой для того чтобы заработать на жизнь, им нужно заниматься разработкой прикладного софта для бухгалтерии, торговли, логистики и тп. Вполне естественно, что всякого уважающего себя советского системщика мысль о написании программы которая создает проводки или продает продажи приводила в состояние близкое к приступу белой горячки. Поэтому, вместо того чтобы писать необходимую клиенту систему автоматизации, эти люди начинали разрабатывать мега-приложение с поддержкой workflow, сущностей, аттрибутов, ролей, событий и тп - в общем всего - о чем они смогли прочитать в книжках по объектно-орентированному проектированию. При этом клиенту рассказывались сказки о том, что как только разработка чудо системы будет закончена, клиент сам, без программирования, сможет буквально за пару часов сам настроить себе требуемое поведение системы. Как правило - довольно скоро заказчик выгонял подобного программиста и брал на его место вменяемого клиппериста. В худшем случае - делалась попытка промышленного запуска разработанной системы, причем чтобы хоть что-то работало, поверх мега-ядра приходилось писать вполне стандартные примитивные кусочки кода, которые можно было очень давно запрограммировать на том же клиппере. В итоге запущенную в конце-концов систему жутко колбасило - поскольку внутри нее боролись "концептуально правильная" мега-система с поддержкой декларативного программирования и криво склеппанная на коленке прикладная система, которая изначально была нужна заказчику.
Причем на мой взгляд - проблема разработанной мега-системы состояла не только в том что при ее разработке случилась подмена целей проекта (вместо прикладной системы - среда разработки), но и в том что вообще система идущая от концепции model-driven architechture,workflow,role-based functionality вообще пригодна только для достаточно узкого круга задач, связанных с обработкой слабоструктурированных данных и плохоформализуемого документооборота.
Теперь посмотрим что мы имеем теперь. Группе сове^H^H^H^H микрософтовских системных программистов и разработчиков компиляторов столкнулась с ситуацией при которой для того чтобы заработать на жизнь, им нужно заниматься разработкой прикладного софта для бухгалтерии, торговли, логистики и тп. Ну и так далее...
То есть - руководство развитием бизнес-приложений было поручено людям, которые в этих бизнес-приложениях не разбираются и не пытаются разобраться. Ну и для того чтобы им не пришлось заниматься так ненавистной им прикладной спецификой, эти люди произвели подмену целей проекта - (я цитирую ) - 1. новый интерфейс 2. ролеориентированный подход 3. использование SharePoint для интеграции. В общем - на мой взгляд - произошла классическая подмена объективно необходимых рынку целей проекта, на те цели, которые хоть как-то понятны его руководителю
Причем что особо забавно - я вот четко понимаю что в существующей Аксапте никаким образом нельзя в целостном виде реализовать поддержку правильного workflow и ролевой модели. Так что если не переписывать аксапту с ноля, то в попытка реализовать эту функциональность приведет просто к появлению нескольких визардов для настройки прав, и какого-нибудь механизма событий, который будет болтаться с боку, но не будет интегрирован с существующей прикладной функциональностью (кстати - они что-то подобное уже кажется сделали в 4ке). Если же они попытаются написать систему с ноля на основе этого подхода, то вместо ERP у них получится система документооборота - любопытная - но в нашей сфере деятельности малоприменимая.
Ну и что забавно - в своей так сказать "тронной речи" Наделла говорит в основном о выпуске новых версий продукта, не понимая что его основной задачей в новом качестве является выстраивание всего бизнеса - от разработки ядра системы до контроля за состоянием проектов, ведущихся партнерами. А он мыслит категориями менеджера комманды разработчиков, для которого работа кончается отправкой системы в нарезку на фирменные CD компании.