Миф о модифицируемости Аксапта, или техническая эстетика.

[stavteam]

Как человек, отдавший Аксапте год своей жизни, хочу поделиться своими мыслями о распостраненном мифе - "Аксапта легко программируется, и в этом ее преимущество".
Действительно, среда разработки почти совершенна. Я не встречал более продвинутой RAD для бизнес-приложений. Есть отдельные проблемы - кривой построитель отчетов, неполноценный SQL, отсутствие перекрестных запросов (сводных таблиц), отсутствие даже намека на историчность данных, однако эти недоработки с лихвой компенсируются мощью расширенных типов данных, методов таблиц, групп полей, построителя запросов, сохраняемых фильтров и автоотчетов, настройкой прав доступа.
Если бы платформа продавалась отдельно - я бы купил ее для целей разработки заказного ПО. Однако - насколько легко модифицировать стандартный функционал, даже при наличии OOD и всех остальных удобств ?
Ответ - модифицировать Аксапту тяжело и в большинстве случаев нецелесообразно. Дело не столько в том, что код не документирован. И не в том, что специалистов мало, и они дорогие. И не в том, что стандартный функционал изначально написан криво.

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

Основная проблема заключается в том, что любое промышленное высокотехнологичное изделие очень тяжело поддается кустарной модификации. Есть у инженеров (я сам потомственный ) такой принцип - совершенная конструкция должна быть КРАСИВОЙ И ПРОСТОЙ. Опытному инженеру необязательно рассчитывать все узлы на прочность. Достаточно оценить внешний вид и сказать - "Это колосс на глиняных ногах. Смотри как некрасиво выглядит. Наверняка в этом месте будет концентратор напряжений." Или - “Такая сложная конструкция не будет работать”. И с большой долей вероятности будет прав.
Посмотрите на автомобили. Какая у них совершенная форма. Как все продумано. Кому придет в голову модифицировать кузов Порше, превращая его в грузовик ? Или как можно модифицировать бытовую стиральную машину ? Или соковыжималку ?
Это ПРАКТИЧЕСКИ НЕВОЗМОЖНО. Потому что, несмотря на поагрегатное проектирование, дизайн конечного изделия создается с учетом ВСЕХ требований. И на приборной доске автомобиля зачастую нет места для дополнительных устройств. Конечно, есть определенный тюнинг, однако мало кто тюнингует иномарку в гараже дяди Вани, хотя восьмерку наверняка ему доверит. У технологичных изделий тюнинг выполняется как правило авторизованными сервис-центрами, и то в очень ограниченных масштабах.
А все потому, что ДОБАВЛЕНИЕ СУЩЕСТВЕННОЙ ДОЛИ ФУНКЦИОНАЛА ПРИВОДИТ К НЕОБХОДИМОСТИ ПЕРЕСМОТРА ВСЕГО(!!!) ДИЗАЙНА. Это так, потому что в высокотехнологичном изделии все компоненты очень связаны, и друг на друга влияют. К сожалению, я пока не знаю удачных примеров "изделий-конструкторов", пригодных на все случаи жизни, хотя ощущаю очень горячее желание потребителей иметь такие изделия. Видимо - технология еще не дозрела. Или - экономически нецелесообразно это. В большинстве случаев конкретное изделие удовлетворяет конкретную потребность и имеет ограниченный набор функций. При этом оно технически совершенно и КРАСИВО.
Вернемся к Аксапта. Система создавалась с претензией на универсальность. Однако получился жесткий набор предопределенных функций. Например - дерево спецификаций. На первый взгляд - очень универсально, однако пример небезызвестной Глории-Джинс, с ее специфичными производственными приказами, процентовками и раскладками кроя, говорит обратное. В данном случае универсальность дерева BOM только мешает. Для того, чтобы удовлетворить реальную потребность компании необходимо дерево строго определенной структуры, где каждый его уровень имеет свою семантику, функциональность и набор атрибутов. Не нужны тут универсальные деревья, а нужны растения вполне определенного вида и свойства.
В этом случае можно модифицировать стандартные деревья, делая их нестандартными, но в итоге очень пострадает эстетичность решения. Продукт будет обладать очень неочевидным функционалом и пользовательским интерфейсом, его будет трудно понимать как программисту, так и пользователю. Будут проблемы с поддержкой. В данном случае целесообразно разработать заказное решение.
Сейчас я понимаю, что две вещи - эргономика данных и эргономика пользовательского интерфейса - очень важны в корпоративном ПО.
Эргономика данных предполагает несколько простых правил:

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

Эти правила легко соблюдать при итеративной разработки приложения "с нуля", и практически невозможно осуществить при "точечной" модификации готовой системы. В случае нашего дерева BOM мы получим несколько бизнес-сущностей в одной таблице, и несколько программистских абстракций. Кроме того – в сложную систему мы внесем еще больше сложности. А как показывает опыт - это неэстетично и плохо поддерживается.
Та же самая ситуация происходит с эргономикой пользовательского интерфейса, которому по определению следует быть простым, понятным и дуракоустойчивым. Желание "максимально сохранить стандартный функционал" приводит к неочевидности и неожиданности системы для конечного пользователя. И еще страшнее то, что при достаточно глубокой модификации часть стандартного функционала может не работать, или работать по другому, а из пользовательского интерфейса этого никак не видно, так как интерфейс универсален.
Необходимо сделать то, о чем я говорил вначале - пересмотреть ВЕСЬ дизайн c целью упрощения и придания эстетичности.
Я не сторонник универсальных решений. Универсальность всегда создается ценой сложности и громоздкости. Я считаю, что клиент платит за конечную функцию, и вправе требовать удобств. Я знаю только одну универсальную программу для бизнеса. Называется Excel. К сожалению, не поддерживает многопользовательской работы, транзакций, имеет ограничения на объем данных, и поэтому применим только в сольной работе.
В настоящее время RAD-средства прогрессируют очень быстро, и очень скоро затраты на разработку ERP-системы под заказ станут меньше стоимости (лицензия + внедрение) тяжелых систем. Это понимает MS. Поэтому для нее так важно удержать под своим контролем именно технологии, а не продукты. Это понимает 1С, развивая в первую очередь платформу, а не функционал. Но я думаю, что работать с этими RAD-средствами должны не наши клиенты, а фирмы-разработчики. Все-таки это наша профессия .

[mazzy]

http://subscribe.ru/archive/economics.book.automation/

Читать лучше в этом порядке
http://subscribe.ru/archive/economic.../04144800.html
http://subscribe.ru/archive/economic.../06144715.html
http://subscribe.ru/archive/economic.../11150014.html
http://subscribe.ru/archive/economic.../19124654.html
http://subscribe.ru/archive/economic.../25154729.html
и т.д...

[Тимур]

Цитата:

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

Товарыш! Акститесь! Никто не шептал на ухо владельцу Глории в 2002 г. покупать Axapta. Ведь что проще: поинтересоваться что используют для автоматизации конкуренты и смежники. Ужели системы для автоматизации дискретных производств? Ан нет, за дармовщинкой-универсальностью потянулся.

Bill of material - категория MRPII. Но этот стандарт не универсален. И есть определенный перечень производств/отраслей, в которых его применение целесообразно.
Если кто-то и вешал лапшу на уши на счет универсальности систем, то это, плиз к ним, к продавцам и PRщикам систем. Им прищемляйте языки прищепками. Никто не мешает клиентам читать побольше литературы профессиональной (APICSовые бюллетени или бюллетени промышленных ассоциаций зарубежных), а не рекламные брошюры поставщиков ПО.
Младшие братья по разуму из российских продавцов систем поют такую же песню про универсальность, только добавляют, что буржуйские продукты ну никак не могут подойти нашим гарным управленцам, потому что не поддерживают просто необходимые для управления функции как N-е количество учетов и печатают даже справки в Военкомат (!) и бланки заявлений для получения загранпаспорта и многие другие гениальнейшие особенности российской действительности.
Так вот ответ простой: учитесь у буржуев и не гонитесь за дармовщинкой.
Зарубежом давно уже определились с отраслевыми решениями, которые поддерживают стандарты управления для данной отрасли. Перетряска рынка ПО происходит лишь по трем причинам:
1) насыщение ниши (все в этой отрасли автоматизированы и не за что брать больше деньги) - в результате разработчика поглощают более крупные собратья. Пример, SSA Global, съевший около 20 вендоров ERP и SCM;
2) появление новых платформ и совершенствование технологий - в результате разработчики либо делают новые версии систем, либо клиент мигрирует. Пример: после появления графических интерфейсов пошла волна перехода к системам, работающим на ОС, поддерживающим такие интерфейсы;
3) совершенствование стандартов управления. Пример: после изменения американского стандарта для химических производств лишь немногие производители систем смогли добавить соответствующий функционал (подробнее на сайте Олина Томпсона).

Поэтому, я считаю, что модифицировать ERP-системы нужно только на уровне дизайна экранных форм и отчетов.Ни разрабатывать новые модули, ни тем более искривлять процессы, зашитые в систему, не только нецелесообразно, но и вредно.
Выбор системы нужно делать таким образом, чтобы прежде всего обеспечить себе необходимый функционал. Казалось бы просто. Ан нет. У наших управленцев часто присутствует свое представление о том, как должны выглядеть автоматизированные процессы, поэтому выбор систем для них превращается в выбор наиболее модифицируемой. Хотя нутром чуют они, что заказная система обойдется им намного дороже и рискованнее. Поэтому ищут универсализм. Ну а на встречу их желаниям выходят господа, которые вчера продавали пирожки, а сегодня ПО и консалтинг, и под удары бубна начинают пляски и песни об открытости кода, универсальности процессов, силе и мощи майкрософт или SAP или Oracle.

[Тимур]

Да. Чуть не забыл.
Модификации необходимы в том случае, если необходимо интегрировать системы разного класса. Например, SCADA и ERP.

[stavteam]

Тимур, несколько параллельных учетов просто жизненно необходимы. Правда - для этого можно поставить рядом две системы - правильную и 1C, однако синхронизация справочников будет гемороем. Поэтому и есть искушение использовать одну систему вместо двух.
А карточки в военкомат - почему бы их и не печатать из системы, где храняться данные ? Модификация на уровне отчетов - я не возражаю.

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

Тимур, дайте пож. пару ссылок на:
> побольше литературы профессиональной (APICSовые бюллетени или бюллетени промышленных ассоциаций зарубежных.
Буду очень признателен.

[Андре]

to stavteam:

По сути дела ответил Тимур. Со многим согласен.

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

[StoneRoller]

to Андре:

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

[Logger]

2 Андре

Но если заказчик готов платить за эти умопомрачителньые модификации, то почему бы и нет ?

Все ваши капризы за ваши деньги...

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

Как выход - проще всего оказывается прогнуть систему ...

[Hamster]

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

Угадайте с 3 раз что случиться со средней зп консультанта в России....

[simply2double]

так много текста ... но осилил... )))

Извечный вопрос, что первичнее курица или яйцо. Меня всегда умиляли люди которые приходят в компанию, котрая в силу некоторых обстоятельств крепко сидит в своем секторе, зарабатывет нормльные деньги, при чем такие нормальные, что это позволяет ей финансировать отнюдь не дешевые игры с IT проектами и заявляют: "Вы мол ребята дураки, бизнем у вас кривой, и вообще вы живете неправильно... Вот у нас есть система, мы вас сейчас извернем под нее, и будет у вас жизнь правильна и красива." Хе-хе... этому даже термин придумали научный - реинжениринг... ))) И это как правило приводит заказчиков в недоумение...
Ведь как правило людям не нужно, что бы их учили жизни... Все гораздо проще..
- Надо лишь обработать первичку, так как ПРИНЯТО в компании.
- Авоматизировать ПРИНЯТЫЙ в компании документооборот.
- Сгенерить НЕОБХОДИМЫЕ аналитические отчеты.
То есть по большому счету дать человеку инструмент, для успешного ведения устоявшегося бизнеса, в котром он преуспел. А не перекорячивать его бизнес. Потому как люди и сами знают, как зарабатывать деньги...

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

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

[ppson]

Цитата:

Изначально опубликовано Hamster
Ок.
На рынке появилась маштабируемая система с супер-пупер архитектурой, подробно документированной системой классов, самой крутой средой разработки.....

1С:8.0?

[Андре]

Цитата:

Что то вывод больно категоричен. Средства разработки по моему полезны для ERP систем.

У меня сложилось обратное представление. Разработка должна быть возможной. Но затраты на нее должны превышать затраты на натягивание стандартного функционала. Чтобы желание попрограммировать не возникало слишком часто.

Проанализируйте ERP-системы. Разве SAP, OEBS, Baan допускают перепрограммирование основных бизнес-процессов. Максимум - формы, отчеты и OLAP. А в Аксапта любой программер может править механизм закрытия склада. Вот только вреда от этого, на мой взгляд, гораздо больше, чем пользы.

Я могу сказать, какая еще система допускает легкую доработку - 1С. Поэтому ее и внедряют программисты, что в общем-то не их дело. Соответственно, я все чаще вижу в форумах сравнение Аксапты с 1С (вот, например http://www.sql.ru/forum/actualthread.aspx?tid=146699 ). Почему то 1С не сравнивают с SAP или Baan. Почему то Аксапту не сравнивают с Sap и Baan.......

[Hamster]

Гм...


"ПРЕДСТАВИМ СЕБЕ что на рынке появилась...."

Так лучше?

[Андре]

Цитата:

Но если заказчик готов платить за эти умопомрачителньые модификации, то почему бы и нет ?

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

[StoneRoller]

Цитата:

Изначально опубликовано Андре


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

А с чего у вас заказчик принимает решения о архитектуре и концепции? Я так полагаю не заказчика это дело? Все модицикации для него "прозрачны". Это внутреннее дело внедренца.

[xonix]

2 simply2double
По поводу бизнес-процессов.
Интересно. Давайте так - вы приводите пример компании, которая стала успешной без всяких там систем, при этом эта успешность не связана с
-административным ресурсом
-торговлей сырьём
-монополией

автоматизация обработки первички - это хорошо и правильно. Если всать на сторону владельца компании, у которой и так всё хорошо, то ему больше и не надо. Я бы даже сказал, ему и автоматизация учёта первички не нужна (у него же итак всё хорошо). Вопрос, что будет с компанией, когда поменяют, например, губернатора или вдруг введут налоги, изымающие сверхпррибыль? Т.е. придётся задумываться, как снижать издержки и воевать за рынок?
Кстати, я был бы рад, если бы мне объяснили, что я не так хожу и в этом причина частой поломки каблуков. По крайней мере, я бы знал, в чём причина. Или посоветовали новые сапоги. Почему нет?

Мне кстати, вот какой вопрос интересен: пришли вы на предприятие, автоматизировали первичку (хотя и до вас они её вели), дали отчёты, которые у них итак были. Документооборот, кстати, можно наример Directum-ом автоматизировать. ВСЁ. Что поменялось? Компания управляться стала лучше? Издержки снизились? Доходность повысилась (за счёт чего)?

Вы определитесь, как вы себя позиционируете. Ведь наверняка же "консультант" называетесь? Так чего тогда консультируете? Как первичку учитывать?

[Андре]

Цитата:

Ведь как правило людям не нужно, что бы их учили жизни... Все гораздо проще..
- Надо лишь обработать первичку, так как ПРИНЯТО в компании.

1c ?

Цитата:

- Авоматизировать ПРИНЯТЫЙ в компании документооборот.

Начиная от Exchange и заканчивая Documentum.

Цитата:

- Сгенерить НЕОБХОДИМЫЕ аналитические отчеты.

Crystal Reports, OLAP...

А при чем здесь ERP ?

[Андре]

Цитата:

А с чего у вас заказчик принимает решения о архитектуре и концепции? Я так полагаю не заказчика это дело? Все модицикации для него "прозрачны". Это внутреннее дело внедренца.

Вообще то я процитировал к чему это:

Цитата:

Но если заказчик готов платить за эти умопомрачителньые модификации, то почему бы и нет ?

[stavteam]

2 simply2double
В принципе согласен.
Только такие компании не от хорошей жизни идут к консультантам за помощью. Масштабы растут, собственник отходит от дел, а документооборот на уровне "Зина (кричит в трубку на весь отдел), а болтики М12Р4Н0.123 когда ожидаются на склад ?". Компания, о которой зашла речь - не исключение. Им действительно нужны эти правильные бизнес-процессы, и они это хорошо понимают, только это - сложный и небыстрый процесс ОБУЧЕНИЯ новым технологиям, один софт ничего не решит, нужна работа с персоналом, много чего нужно еще...

[simply2double]

Цитата:

Изначально опубликовано Андре


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

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

PS Почему-то так хочеться считать себя умнее других. В особенности умнее этих толстых буржуев.