Извечный вопрос: кодить или параметризовать.

[ushastik]

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

1. В таблице "InventJournalName(названия журналов управления запасами)" создается куча настроек, по одной на каждый кастомизированный журнал. Затем модифицируется код стандартного журнала "InventJournalLossProfit(прибыль/убыток)". При этом в соответствующих местах кода проверяется наличие той или иной настройки и в зависимости от этого скрываются контролы, запрещается редактирование, выводятся кнопки и т.д.

2. Под каждый бизнес-процесс создается новый журнал(форма), код которой во многом повторяет код стандартной формы, но при этом он уже максимально кастомизирован, и никаких настроек нет.

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

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

Хочу услышать мнение, с точки зрения стратегической. Как правильнее кастомизировать Аксапту. При этом надо учитывать именно качество решения с точки зрения смены версий, передачи проекта другой команде, разрастания объемов проекта. Должнен же быть паттерн на эту тему. Буду очень благодарен за коментарии

[EVGL]

Не создавайте новых форм путем копирования сложных системных! Рассмотрим ваши два варианта с точки зрения "подъема кода" на новые версии:

1. Сильно модифицирована одна форма: запускаем инструмент сравнения кода, поднимаем на новую версию. Условно говоря, X дней работы.
2. N вариаций на тему одной формы: подняли исходную InventJournalLossProfit, потом начинаем мучительно вспоминать, чем же отличаются друг от друга и от исходной остальные формы. Сравниваем каждую форму с исходной. Порядка N*X дней работы.

Результат: стоимость поддержки второго варианта вплоть до N раз больше.

[AKIS]

ushastik,

На твоем месте я бы всеми силами сопротивлялся модификации кода. Вплоть до ультиматумов пользователям "привыкайте работать с тем что есть, а не нравится - ...................".

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

Все, что написано об Аксапте в части "легкости перехода" - верно процента на 3. В реальности, одна лишняя строчка в одном методе может вам потом стОить несколько сотен баксов...

Так что, не первый и не второй способ. Вместо этого - меняйте бизнес-процессы.

Поверь старому человеку - это ВЫГОДНЕЕ и ДЕШЕВЛЕ!!!

[ushastik]

2 EVGL:
Понял, спасибо. Меня единственно что смущает - одна форма по сути обслуживает сразу несколько бизнес-процессов, и сам ее код становится все запутанней. Но я учту замечания по поводу смены версий.

2 AKIS:
Я это и делаю. Только к сожалению мы - производство, и логистическая цепочка у нас другая, и просто сложнее мы чем Аксапта. Потом у меня есть свое личное мнение - IT отдел должен служить основному бизнесу, а не наоборот. То есть пользователям должно быть удобно. Это экономит время и нервы. То есть должна быть дуракоустойчивость системы. Можно полагаться на должностные инструкции, но я бы предпочел иметь непробиваемое рабочее место для данного бизнес-процесса. Если особенности софта ставить впереди бизнес-процессов, нас могут не понять. Возможно, я перегибаю.

[mazzy]

ИМХО: тут народ уже так привык к словам об уникальности предприятия... когда на проверку оказывается, что все стандартно и уже реализовано... просто спрашивающий не нашел... в общем про уникальность и про "больше, чем Аксапта" сходу верится с трудом... хотя это конечно же возможно.

В Аксапте действительно есть вещи, которые хочется добавить. Но журнал ли это? И действительно ли вы натолкнулись именно на них...

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

[uvi]

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

[ushastik]

Цитата:

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

Дело не во внешнем виде. Дело в дополнительной функциональности. Которая одним нужна, а другим вредна. Этот вопрос конечно можно решить путем настроек прав доступа на группу пользователей, но как ты организуешь такой доступ: "аналитику можно задать один раз и больше не изменять".

[bucken]

Ушастик - очень стильный у вас аватор (картинка для ваших сообщений).

[LCh]

Цитата:

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

Дело не во внешнем виде. Дело в дополнительной функциональности. Которая одним нужна, а другим вредна. Этот вопрос конечно можно решить путем настроек прав доступа на группу пользователей, но как ты организуешь такой доступ: "аналитику можно задать один раз и больше не изменять".

Когда возникает такой вопрос на личном опыте убедился, что просто мало фактов для принятия решения. Стандартный функционал - всегда плюс. Тем более, что Microsoft Axapta спроектирована _очень_ грамотно (за исключением редких промахов).

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

Кстати, ищете ответы на вопросы - смените аватар. Здесь люди знания ищут, а не члены разглядывают. И куда смотрят админы? =\

[mazzy]

некоторые админы проморгали.

Извините, я не вглядывался и не обратил внимания. komar сработал отлично.
Письмо с просьбой сменить аватара послано участнику ushastik.
Спокойствие.

ushastik, надеюсь у вас хватит доброй воли и вы не будете вынуждать применять админпанель.

[ushastik]

2 Lsh:
Мне вопрос глупым не кажется, тем более что я получил несколько довольно грамотных ответов. Фактов у меня мало, согласен, поэтому и спрашиваю. Было бы много фактов, я бы сам отвечал.
2 All:
За аватар прошу прощения, хотя он мне нравился.

[komar]

Рискну предположить, что лучше все-таки несколько форм. Доводы такие:
-суперформа будет жутко тормозить, много мелких тормозить не будут
-"мучительные поиски" заменяются грамотным документированием разработки
-мелкие формы по минимуму отличаются от стандартной, суперформа значительно отличается. Соответственно, обновлять ее труднее.
-много одинакового кода писать не надо, есть же копирование, есть же использование стандартных классов
-легче разграничивать доступ

[Тимур]

Думаю, что прежде всего необходимо классифицировать предполагаемые модификации исходя из предполагаемых путей реализации:
0) организационные меры (инструкции, приказы, СтП, ТПУ и пр.)
1) сокрытие лишних полей и осуществление прочего дизайна форм с настройкой под конкретное АРМ;
2) изменение прототипа система (пересмотр настроек);
3) написание новых журналов;
4) добавление/изменение логики обработки стандартных журналов системы:
а) незначительные модификации (например, новое поле);
б) значительные модификации (затрагивают функционал других частей системы).

Пункты следует применять последовательно и итерационно, начиная с (0), то есть по максимуму решить все пунктами (0), если не получается - то (1) и т.д.
Что лучше делать (3) или (4а) - вопрос сложный.
Осуществление пункта (4б) лучше делать после согласования со специалистами MBS , а в ряде случаев с другими партнерами/клиентами MBS, желательно под рукой иметь смету в трудовых/денежных измерителях на реализацию (включая документирование) и на дальнейшую поддержку и апгрейд.

P.S. Интересно, что у Вас попадает под пункт (4б) ?

[AKIS]

Цитата:

Потом у меня есть свое личное мнение - IT отдел должен служить основному бизнесу, а не наоборот. То есть пользователям должно быть удобно. Это экономит время и нервы

Вы совершенно правы, ушастик - должен служить. В том числе: должен удерживать бизнес от неразумных трат сил, времени и (всегда как следствие) - денег.

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

А удобство, я всегда говорю - вопрос субъективный. Мне в России казалось НЕудобным ездить на машине с коробкой-автоматом. В Канаде мне кажется НЕудобной езда с механической коробкой (каковая тут крайняя редкость).

Вашим пользователям может быть удобно приходить на работу часам к 10, в пляжных шортах и пить пиво на рабочем месте. И это им ТОЖЕ будет экономить время и беречь их нервы. Готов ваш бизнес пойти им навстречу в этом? Объясните мне, почему "удобство нажимания кнопок" является "оправданным", а пития пива - нет?

Все в конце концов дело привычки. Если вы не пойдете на поводу у своих юзеров - через год они и помыслить себе не смогут, как вводили данные "по-старому".

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

[AKIS]

Цитата:

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

Тогда, скорее всего, вам и нужна не Аксапта, а какая-то другая система. Может SyteLine, MFG/PRO, а может и Baan

[Тимур]

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

P.S. Надеюсь не исказил смысл?

[Тимур]

А может что-нибудь из решений для предприятий легкой промышленности ?

[AKIS]

Цитата:

Изначально опубликовано Тимур
AKIS

P.S. Надеюсь не исказил смысл?

Наоборот, Тимур, выразил ее гораздо лучше меня Я б так умнО выражаться ни в жисть не смог

Bottom line: Каждый в компании должен делать свое дело. ИТ-департамент занимается информационной инфраструктурой предприятия. Точка. Информационная структура работает (обеспечена техническая возможность ввода, обработки, хранения и вывода данных) - ИТ-департамент справляется со своей задачей.

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

[Fisher]

Ничего себе.
Вы господа внедренцы получается точно знаете,
что нужно клиенту не интересуясь его мнением.
Вы считаете что процессы реализванные в Axapte абсолютно оптимальны и непогрешимы.
Задача ИТ отдела - оптимизация процессов, а не перепроектирование или реинжиниринг.
Это совершенно другие задачи,
ими занимаются другие специалисты

[ushastik]

Насколько я могу судить, наблюдая картину со стороны, внедрение ИС - это одно, а управленческий консалтинг - это другое. То есть, грубо говоря, определять, куда товар выгружать, как его проверять, куда транспортировать, в каких ящиках хранить, какое оборудование использовать, сколько людей надо, как разделить склад - этим занимается отдельная консалтинговая компания за отдельные деньги. Задача отдела IT - организовать учет этого уже де-факто существующего процесса. Мы можем выступить с предложениями и пожеланиями, но я есть понятие компетенция. И этот вопрос не в компетенции IT-консультантов. Как то мы навешиваем на IT-специалистов задачи, в которых они не соображают. Простите, если глючу