про интервью

[axoebsap]

Добрый день! Поскольку тут участники по идее с опытом в разных системах есть вопрос. Я с 2001 года в ERP 2 года консультант по аксапте (финансы, материалы), 5 лет консультант OeBS (производство, упр. проектами, Worfflow), почти 5 лет руководитель проектов SAP. Никогда не писал код в ERP, но программировал в очень давние времена. Вопрос в следующем - на меня по нраволке сотрудника Microsoft (мой старший сын, работает в Бельвью уже три года) вышли рекрутеры из MS с "оттуда" и я заппалоился на позицию MS Dynamics Solution architect в Москве ина анадлогичную вакансию в Редмонде и прошел скрининг интервью, теперь жду технического - и в резюме и в интервью я совершенно четко дал понять, что функционала аксапты не помню в упор, кода ьв ней не писал вообще, а в сапе и настроек не знаю, так как только руководил проектами (всего 4 крупных проекта у меня за плечами и куча прсейлов). Соответственно вопрос - что у меня могут спрашивать ан техническом интервью?

В требованиях в вакансии нарписано - занание одной из систем ERP, сильные навыки управления проектами, базовы знания одной из технологий MS. Я когда -то писал код на MS SQL

Может кто-то проходил через что-то попдобное

[zemlyn]

God save this ERP...
P.S. простите не удержался...

[lvan]

это вакансия не для вас, забудьте про неё
вам, вероятно, предложат другую позицию просто

[pitersky]

Цитата:

Сообщение от lvan

это вакансия не для вас, забудьте про неё
вам, вероятно, предложат другую позицию просто

Очень точно сказано
Помнится, когда я в MS послал резюм по Аксапте, то ихний эйчар на меня вышел с вакансией разработки окошечного ядра

[macklakov]

Хорошая заявка на лучший анекдот 2014 года!

[EVGL]

Этот скепсис излишен. Люди с таким послужным списком успешно работают в MCS к полному восторгу клиентов. Умение писать код в AX - не самая большая ценность для руководителя проекта или архитектора. Если бы в AX сделали такую же главную книгу, как в OeBS, упал бы груз забот с плеч.

[macklakov]

Цитата:

Сообщение от EVGL

Если бы в AX сделали такую же главную книгу, как в OeBS, упал бы груз забот с плеч.

Так вот же он счастье! Только руку протянуть. Давай человеку поможем, а он нам сделает ГК как в OeBS?

Уважаемый axoebsap, не могли бы Вы опубилковать информацию о вакансии, которую Вам удалось добыть?

[Logger]

Цитата:

Сообщение от EVGL

Умение писать код в AX - не самая большая ценность для руководителя проекта или архитектора.

Хм. А что вы вкладываете в понятие архитектор ? И что он должен уметь ?

Цитата:

Сообщение от EVGL

Если бы в AX сделали такую же главную книгу, как в OeBS, упал бы груз забот с плеч.

Ээээ...
А вот доводилось слышать мнение что главную книгу в Dax2012 слизали с OEBS. И, мол, это было не лучшим решением. С OEBS не знаком, поэтому за что купил за то продал.
А откуда у вас такое востороженное мнение по OEBS ?

[mnt_dx]

Цитата:

В требованиях в вакансии нарписано - занание одной из систем ERP, сильные навыки управления проектами, базовы знания одной из технологий MS. Я когда -то писал код на MS SQL

Чтобы быть архитектором, надо очень хорошо знать систему, в том числе программирование, и в базах данных тоже разбираться. Иначе на основе чего он будет принимать решение о реализации задач тем или иным путем?

[Ivanhoe]

Цитата:

Сообщение от mnt_dx

Чтобы быть архитектором, надо очень хорошо знать систему, в том числе программирование, и в базах данных тоже разбираться. Иначе на основе чего он будет принимать решение о реализации задач тем или иным путем?

Откуда такое мнение? Есть четкое определение "архитектор"? На практике сталкивался как минимум с двумя понятиями. 1. "Главный разработчик" - он действительно должен знать все о программировании, понимать функциональность и т.п. 2. "Архитектор решения" - это человек, который отвечает целиком за итоговое решение (куда входит не только сама Акс, но и много чего еще) - вот там знание программирования может иногда даже мешать. И как правильно оперирование достаточно крупными блоками типа "Ценообразование", "Планирование" и т.п.

[mnt_dx]

Цитата:

Сообщение от Ivanhoe

Откуда такое мнение? Есть четкое определение "архитектор"? На практике сталкивался как минимум с двумя понятиями. 1. "Главный разработчик" - он действительно должен знать все о программировании, понимать функциональность и т.п. 2. "Архитектор решения" - это человек, который отвечает целиком за итоговое решение (куда входит не только сама Акс, но и много чего еще) - вот там знание программирования может иногда даже мешать. И как правильно оперирование достаточно крупными блоками типа "Ценообразование", "Планирование" и т.п.

Есть список требований http://ru.wikipedia.org/wiki/%D0%90%...BD%D0%B8%D1%8F там и файлик с умениями.

Я правильно понимаю, что по-вашему архитектор "не должен знать программирование", "не должен понимать функциональность"?

[macklakov]

Цитата:

Сообщение от Ivanhoe

Есть четкое определение "архитектор"?

Ну о чем мы спорим? Пусть требования к кандидату покажет, сразу все вопросы отпадут.

[oip]

Цитата:

Сообщение от Ivanhoe

Откуда такое мнение? Есть четкое определение "архитектор"?

Определение MS Dynamics Solution architect? Есть, конечно. В Sure Step.

Цитата:

MS Dynamics Solution Architect

Purpose
To provide both technical and functional knowledge of the Microsoft Dynamics product being implemented and all related Microsoft technologies required for the implementation.

Description

The Solution Architect:

· Establishes an overview of the requirements defined by the customer; drives definition of business, technical, and architectural requirements, and recognizes any inconsistencies, assumptions, and critical elements that must be considered in an Enterprise solution
· Responsible for defining the technical solution blueprint for the Microsoft Dynamics solution (addressing all high-level business and technical requirements) included in the Customer proposal; participating with both functional and technical specialists in the Fit/Gap analysis
· Demonstrates experience in use of common software implementation methodologies, including an understanding of Microsoft Sure Step; understands and applies relevant problem solving frameworks and techniques to client engagement and internal projects.
· Defines the functionalities, use cases, interfaces, and/or load scenarios for which a POC may be needed, and outlines any prototypes as required.
· Contributes to the scope management, risk management, meaning identification, evaluation and mitigation plan.
· Helps drive the estimation of the effort to realize the implementation of the proposed solution
· Interacts with stakeholders in the IT and business groups to provide the engineering view of the users' vision regarding the structure and function of the system, as well as the areas in which the system must be able to evolve.
· Develops the integration strategy, if required, following fundamental architectural concepts and in accordance with customer’s requirements and constraints, to ensure that Microsoft solutions and customer’s data sources are appropriately integrated.
· Plans and oversees the execution of the User Acceptance test in collaboration with the project manager and gathers early user feedback on the solution from key customer stakeholders.
· Validates that the solution will satisfy the customer’s requirements after a POC or UAT.
· Guides the project through the development and implementation phase to handle solution oriented topics.
· Demonstrates strong qualitative analytic capabilities, particularly in relevant strategy formulation areas such as client, industry, and management issues/challenges.
· Demonstrates growing knowledge base regarding current issues and trends, key drivers, and their impacts in relevant industries and Microsoft technologies.
· Demonstrates ability to plan and manage engagement work and allocate resources appropriately under time, quality and budget constraints.
· Contributes to company growth and revenue generation through identification and proactive pursuit of new revenue opportunities.
· Works collaboratively with practice leadership team to grow, develop and enhance solution best practices, tools and methods, and intellectual property.

Skills

Soft Skills

Business and technical insight
Creative problem solving and conflict resolution
Excellent facilitation, discovery, analysis, and prototyping skills
Team-oriented; willing to align work with team’s priorities and goals
Clear and effective communication, in written and verbal formats
Strong customer focus

Functional/Technical Skills

Demonstrated ability to:
· Apply high-level solution architecture and design
· Analyze, understand, and dissect business processes
· Analyze an organization’s IT infrastructure
· Apply Microsoft integration techniques effectively
· Use data- and process-modeling techniques
· Perform hardware sizing based on architecture

Demonstrated experience with:
· Implementation Methodology
· Microsoft .NET technology, the Microsoft Visual Studio development system, and Microsoft Dynamics-specific development environments
· Local and wide-area networking
· Desktop and server operating systems
· Server technologies: Microsoft SQL Server database, Reporting Services and Analysis Services, Web servers, etc.
· Internet technologies: Microsoft Internet Information Server (IIS), Microsoft BizTalk Server, firewalls, etc.
Successful completion of applicable product certification exam

[ax_mct]

Цитата:

Сообщение от Ivanhoe

Откуда такое мнение? Есть четкое определение "архитектор"? На практике сталкивался как минимум с двумя понятиями. 1. "Главный разработчик" - он действительно должен знать все о программировании, понимать функциональность и т.п. 2. "Архитектор решения" - это человек, который отвечает целиком за итоговое решение (куда входит не только сама Акс, но и много чего еще) - вот там знание программирования может иногда даже мешать. И как правильно оперирование достаточно крупными блоками типа "Ценообразование", "Планирование" и т.п.

Solution Architect достаточно часто попадается по вакансиям в UK и редко когда агенты и даже клиент имеют формализованное представление что это за зверь такой.
Когда спрашиваешь это Functional или Technical Solution Architect обычно просто зависают в прострации, о методологиях вообще и в частности о MS Sure Step лучше не заикаться - это слишком сложно.

В каждой компании это своя затычка, стандарта нет (я говорю про UK). Просто нужен человек который все возьмет в свои руки а как его назвать никто не знает. C таким уже успехом его можно назвать руководителем направления или начальником департамента.

Чаще всего это то что в России "старший консультант" с дополнительными (частичными) функциями по продаже (sales) и руководству проектом.

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

Конечно если речь про MS то там должно быть более формально.

[macklakov]

Цитата:

Сообщение от Logger

А вот доводилось слышать мнение что главную книгу в Dax2012 слизали с OEBS. И, мол, это было не лучшим решением.

Сегментированные счета еще и в GP есть. Так что сложно сказать, откуда именно эти "американские субконто" взялись.
Но слизывали точно. И в GP и в OEBS над сегментами нет надписей. Точно так как их не было в ранней версии AX 2012. Т.е. чтобы с ними можно было вменяемо работать, их значения должны быть фиксированы для всей системы. Иначе непонятно, что какой сегмент означает. Это делает сегменты аналогом традиционных аксаптовских сквозных аналитик в версиях до 2009 включительно. Разница в том, что если в аксапте аналитики видишь в проводках, то здесь их видно прямо в ГК. К примеру, если создаешь отдел и начинашь для него постить проводки, генерируются новые суб-счета в ГК и проводки разносятся на них.

[fed]

Поскольку Женя стушевался из этой темы, я пожалуй что слегка разьясню.
Около пары лет назад в Микрософте создали несколько Dynamics Center of Excellence. (CoE) Начальная официально заявленная цель этих центров состояла в управлении наиболее важными Dynamics проектами, привнесению новых знаний в ряды партнеров и тп. В полном соответствии со старым анекдотом (как не пробую собрать - все равно пулемет получается), CoE превратился просто в очередной sales engine. Поэтому хотя в этих CoE имеются позиции Прикладного и Технического Архитектора - все равно прикладной архитектор работает просто как сейл (то есть - много-много говорит с использованием всяких деловых buzzwords), а технический архитектор это по факту просто инфраструктурный консультант (занимается типа сайзингом, тюнингом производительности, проверкой best practice при разработке и тп. Ах да - еще их иногда на продажах посылают окучивать клиентских технарей). Так что заявленных целей CoE не выполняют.
По моим сведеньям, недавно, где-то в штаб-квартире разработки в редмонде задумались все-таки создать свою внедренческую структуру, чтобы таки наладить хоть какой-то фидбек с внедрений в R&D. Вероятно именно туда и сватают топикстартера. В целом - идея неплохая, но боюсь что как всегда (см - историю про пулемет). Кроме того - все-таки для этой позиции надо бы не только бизнес понимать, но и Аксапту знать выше среднего. (Ну то есть - не про каждую галочку конечно, но какой-то helicopter view того как бизнес-процессы в системе реализуются - должен быть.)

[Logger]

Походу надо ветку форкнуть на 3.
1. Про оригинальную тему
2. Про архитекторов и.т.д.
3. Про разноску ГК в аксапте и сравнение с другими системами. (кто на ком стоял,и.т.д.)

[EVGL]

Определение архитектора дано и соответствует определеию Ivanhoe + специфика Microsoft: должность Microsoft Consulting Services Solution Architect предполагает, что часть времени будет потрачена на pre-sales вне зависимости от того, CoE ли это, или нет.

В AX не хватает автоматизации двойной бухгалтерии с параллельными ГК по счетам концерна и счетам локальным (что имеется в OeBS), а также разведение понятий компании и ГК (см. Mandant=компания, Buchungskreis=бухгалтерская книга в SAP). Ну и нормальной выверки банка нет. И казначейства. И поддержки кредитов.

[axoebsap]

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

По опыту работы своих многчисленных коллег из Борласа и Oracle, которые сейчас работают в SAP СНГ на аналогичной позиции business solution architect могу сказать, что скорее всего прав коллега, утверждающий, что это presale или просто Sale позиция, но почему-то заявленная как консалтинг (видимо из серии хотели как лучше, а получилось как всегда). И в SAP и в Oracle эти позиции вне консалтинга. Тем не менее намерен все же посмотреть, что будет дальше, интервью с менеджером мне назначили на середину марта, у нее лично и спрошу, что же от меня ожидают - попытка, она как известно не пытка.

Что касается presale , то и на текущей позиии РП SAP ERP этим приходится заниматься процентов 40 времени как минимум, даже при реально идущем внедрении.