Программист Axapta. Белая дача.

[IvanHARD]

Профессиональные требования:
- Опыт разработки в Axapta от года;
- Понимание архитектуры системы и концепции построения объектов;
- Хорошее знание X++, желателен опыт разработки на других объектно-ориентированных языках (C++, Object Pascal, Java);
- Опыт разработки и оптимизации запросов MS SQL (опыт администрирования желателен);
- Знание функционала системы и основополагающих принципов построение бизнес-процессов предприятий в области складской логистики, торговли, производства;
- Умение работать по ТЗ, желателен опыт написания ТЗ;
- Желателен опыт работы с Crystal Report;

Личные данные:
- 22-35 лет;
- Образование высшее техническое (желательно АСУ, прикл. математика и т.п.);
- Умение работать в команде;

Обязанности:
- Модификация стандартного функционала Axapta в рамках проекта внедрения, разработка новой функциональности, построение отчетов;
- Поддержка доработок и развитие функционала системы после завершения внедрения;
- Документирование модификаций и разработок;

Условия:
- График работы с 9.00 до 18.00;
- Зарплата белая по итогам собеседования (от 1800$ net);
- Офис: ЗАО «Агрофирма «Белая дача», г.Котельники Люберецкого района МО (ст.м. «Кузьминки», «Люблино» - 20 мин. от метро).

Резюме направлять по адресу: afedyaeva@belaya-dacha.ru

[IvanHARD]

Итак, ставки повысились.

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

В рамках проекта автоматизируются два юрлица (ответхранение, производство салатов), в перспективе другие компании группы.

С нетерпением ждем пополнения наших рядов!

неплохо

[new-comer]

Цитата:

Изначально опубликовано IvanHARD
проведено разделение работ между консалтинговой компанией и рабочей группой

это про разработку модификаций? ряд крупных проектов это сгубило... об успехах такого подхода не слышал... в любом случае, успехов тебе, IvanHARD! :-)

[IvanHARD]

При здравом подходе и заинтересованности обеих сторон ничего опасного в этом нет.

Спасибо за пожелания! Будем стараться.

[Белая Дача]

И мы надеемся, что всё получится

[axLog]

Цитата:

Изначально опубликовано IvanHARD
.. составлены перечни модификаций... переходим к стадии детального проектирования.

Н-да.. дизайн-проекта еще нет, а перечни модификаций уже составлены. Странно работаете.

[IvanHARD]

Цитата:

Изначально опубликовано axLog
Н-да.. дизайн-проекта еще нет, а перечни модификаций уже составлены. Странно работаете.

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

А вот отрывок из подэтапа "Анализ покрытия функциональности":
По результатам анализа применимости стандартной функциональности системы Аналитик ЦР совместно с Разработчиком (или Менеджером разработки) оценивают объем работ (обычно, в часах), необходимый для реализации в системе недостающей функциональности.


Читайте классикофф, Батенька!

[new-comer]

Цитата:

Изначально опубликовано IvanHARD


Не буду вдаваться в прения, а просто процитирую отрывок из описания этапа Анализа от MBS:
...

axLog, а ведь IvanHARD прав в данном случае.

[xonix]

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

А анализ МБС, по видимому, начинается после того, как появится документ, который собстно описывает желаемые бизнес процессы.

В третьих, то что вы перечислили - такие же классики, как группа Иванушки Интернейшнл

[axLog]

xonix меня правильно понял. Ну пусть не дизайн-проект, пусть функциональный дизайн, дело в сути: анализ приводит к принципиальному пониманию того, что есть сейчас и что нужно (безотносительно к к.-л.системе вообще!) ; дизайн описывает как эти требования будут реализованы в системе. Только после этого можно сравнивать стандартную систему с дизайном и писать список модификаций. И еще: речь по-видимому нужно всегда вести о сравнении именно со стандартной системой, несмотря на то что многие компании ставят в качестве базовой свою версию, доработанную и исправленную на предыдущих проектах. Поэтому модификации - тоже относительно стандартной системы. Следствие : если в собственной базовой версии уже что-то сделано, что нужно на данном проекте, то есть модификация по сути уже не нужна, она все равно должна быть включена в список и описана.

Описание технологии внедрения от MBS пишется живыми людьми, а людям свойственно ошибаться. На мой взгляд, эти описания содержат ошибки. Было бы интересно узнать поименно авторов и их проекный опыт.

[IvanHARD]

2xonix

На стадии анализа производится прикидка функциональности системы на бизнес-процессы предприятия. На основании этого и составляется перечень модификаций функциональности. Естественно, что там могут быть не отражены мелочи, но процентов 85-95% при вдумчивом подходе в него попадет. По-другому и бюджет проекта распланировать трудно будет, и загрузку людей.

На стадии дизайна уже идет прорисовка процессов до мелочей...

У нас все аналогично - в общем виде уже проработаны бизнес-процессы.

[IvanHARD]

2axLog:

У нас уже после обследования есть:
1. Четкое видение желаемого
2. Четкое представление о решении консалтинговой компании
3. Представление о способах перекладки БП в систему

Даже на стадии диагностики приходится делать прикидки на систему, т.к. иначе невозможно определить ее приминимость для предприятия. Если этого не делать, то могут получиться проекты со 100% заменой стандартной функциональности. Нужна ли такая система?

[axLog]

Цитата:

Изначально опубликовано IvanHARD
2axLog:

У нас уже после обследования есть:
1. Четкое видение желаемого
2. Четкое представление о решении консалтинговой компании
3. Представление о способах перекладки БП в систему

Даже на стадии диагностики приходится делать прикидки на систему, т.к. иначе невозможно определить ее приминимость для предприятия. Если этого не делать, то могут получиться проекты со 100% заменой стандартной функциональности. Нужна ли такая система?

Так вы же уже заключили договор, верно? Так что прикидывай-не прикидывай применимость, а делать все равно придется на этой системе и с этой командой. Это первое.

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

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

[new-comer]

на мой взгляд, при таком подходе - "с точностью до необходимых полей экранных форм ... для каждого конкретного функционального рабочего места" - Вы рискуете за деревьями не увидеть леса . Это, безусловно, нужно, но потом... когда прийдет время писать EDD (в терминах онТаргет).

[xonix]

Экранные формы - это перебор.
Я бы остановился на UML/eEPC/кто что любит диаграммах БП, задокументировал основные особенности БП текстом отдельно.
НО!
Для того, чтобы анализировать "отклонения" неплохо бы всё-же сначала задокументировать что есть и подтвердить документ (ваше понимание процессов) у заказчика. Ясен пень, что если очень умные диаграммы рисовать - то смысла 0. Надо спуститься с небес и простыми схемами, картинками, текстом зафиксировать положение.
А анализировать "на живую" - это можно конечно.. Только что потом делать, если выяснится, что "не поняли друг друга" причём по принципиальным (для вас или для заказчика) моментам?

Прикидку можно вообще за неделю сделать... Только куда эту прикидку потом подкладывать, когда выплывут "несоответствия", да ещё такие, что пол системы карячить придётся?

[maximus]

xonix & axLog & IvanHARD

Господа! О чем спорите? Я ни в коей мере не разработчик on target, но хотел бы высказаться. В on target четко выделены этапы, которые не допускают разночтений:
- диагностика - выявление бизнес процессов;
- анализ - изучение бизнес процессов и разработка функциональных требований к ним (преценденты в терминах UML);
- дизайн - создание концептуального дизайна(ТЗ; описание системы с точки зрения бизнес процессов) и программного дизайна (описание системы с точки зрения пользователя);
- ...

И это общий подход к моделированию систем с точки зрения UML, только назван другими терминами. Опыт методологов тут ни при чем.

ИМХО, на Белой Даче первые два этапа "слили" в один. Не уверен, правда, что функциональные требования фиксировались на носителе.
На мой взгляд, понимание термина "перечни модификаций" у axLog и IvanHARD разные (программные модификации и бизнес-модификации соответственно

[IvanHARD]

Всем доброе утро! Погодка шепчет...

2xonix:
Разве я говорил, что нет описания существующей ситуации? Конечно есть! Есть не только оно, но и описание будущей организации бизнес-процессов, а также отклонения между этой организацией и функциональностью в системе, что суть и есть модификации.

2axLog:
Господи, кто ж говорил что дизайна не будет? Будет, конечно, но проект планировать нужно до дизайна. Поэтому и появляются приблизительные перечни модификаций. Модификации в стиле "положить текстовое поле ААА на закладку БББ" здесь не столь важны. Важно общее видение, общий объем работ по изменению ключевых алгоритмов. Безусловно, что-то сейчас не будет учтено, тем не менее, достигнута договренность о сферах отвественности.

[IvanHARD]

Ребята, ждем!

[Anais]

2 new-comer

Цитата:

Изначально опубликовано new-comer
это про разработку модификаций? ряд крупных проектов это сгубило... об успехах такого подхода не слышал... в любом случае, успехов тебе, IvanHARD! :-)

А можно поподробнее? Где, кто, когда? И, главное, в чем причина провалов? Почитать где-нить можно об этом?