ОПРОС: Отраслевое решение миф или реальность

[ALEG]

Начало тут

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

Для того, чтобы иметь факты, я разработал данный опросник.

ОГРОМНАЯ ПРОСЬБА, ЕСЛИ ВЫ В ТЕМЕ (ВНЕДРЕНИЯ ERP СИСТЕМ), ТО ПОТРАТЬТЕ ПАРУ МИНУТ.

В качестве вкусностей могу разослать по окончанию сырые данные и сами поанализируете.

Также огромная просьба - попросите ваших друзей, кто тоже в теме.

Нажмите тут для того, чтобы принять участие в опросе

[glibs]

Цитата:

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

...
лично я все больше и больше склоняюсь к мнению, что отраслевое решение - миф
...

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

Вообще, мнение разделяю. Аксапта... у нас... да и на Западе, хотя и не так глобально... принято ее кастомизировать при внедрении. Тут уже с отраслевым решением как бы заминка. Правильнее говорить будет об отраслевых наработках. Фактически примерно так и происходит, насколько мне известно.

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

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

А вообще я верю, что хорошие отраслевые решения бывают . Вот только массовым явлением они не являются.

[EVGL]

Цитата:

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

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

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

Все, обиделся, никаких двух минут тратить не буду.

2 glibs: читал я требования MS к вертикальным решениям. Злился и плевался. Одно требование по онлайновой документации чего стоит: в 4.0 такая документация стояла бы как остров посреди бескрайнего океана. Или требования по Best Practice, которые в итоге сводятся к проставлению строчки "//BP Deviation" в заголовке каждого display-метода. Смешно.

[ALEG]

2 GLIBS - мои размышления очент похожи. В 95% случаев за отраслевое решение выдают отраслевой опыт + поделки с прошлых проектов.
2 EVGL - Значит Ваше решение относится к тем 5%, которые реальные решения.

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

[miklenew]

Вот в SAP отрослевые решения выпускает сам SAP.
Но и сравнивать есть что, наши 2 тыс таблиц и их 30 тыс.
Представьте последствия после того как у нас появяться 30 тыс таблиц.
Это сколько же связей в голове держать?
Значит больше людей нужно будет держать для обслуживания.
Да и потом, если MS сделает такой шаг, цена за продукт будет такае же как в SAP.
Есть над чем задуматься.
Стоит ли мечтать о том чего нет.
Или просто наладить у себя процесс работы как нужно и получить в итоге желаемое.

[ALEG]

а несут ли дополнительную ценность эти 30 тысяч таблиц отраслевых?

[miklenew]

Цитата:

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

а несут ли дополнительную ценность эти 30 тысяч таблиц отраслевых?

Мне кажется это лучше спросить у Pavel. Он больше расскажет о SAP, если захочет.
Я книгу только начал читать.

[ALEG]

ну если Вы книгу уже начали читать, то можно и в резюме уже записать ))))

[В гостях:))]

В SAP многие из отраслевых решений ОЧЕНЬ сильно отличаются от стандартного ERP или серьезно расширяют его возможности. Например, из тех с которыми я близко сталкивался: SAP Retail радикально отличается от SAP ERP - другая орг. структура, другой механизм планирования пополнения запасов, другой контроллинг, другие продажи. SAP Apparel and Footwear Solution добавляет к стандартному ERP возможности учета по цвето-размерным матрицам, коллекционное сезонное планирование, аналитику по категориям продукта и т.д. В SAP Catch Weight Management (решение для мясопереработки) добавлена возможность учета в двух единицах измерения без фиксированного коэффициента пересчета. Соответственно, себестоимость считается по штукам и килограммам по отдельности и т.д. SAP for Beverages добавляет, например, операции с возвратной тарой и сценарий прямых поставок в торговые точки.
И так, в принципе, по всем отраслям. Могу сказать, что при продаже это сильно упрощает демонстрацию решения клиенту. При внедрении - накладывает на консультанта дополнительные требования (он должен разобраться в функциональности отраслевого решения), но в конечном итоге тоже приближает конечный результат - успешный продуктивный старт.

[miklenew]

В гостях) а как программисты справляются с 30 тыс таблиц?
Это же сколько связей в голове надо держать.

[DanielG]

Цитата:

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

В гостях) а как программисты справляются с 30 тыс таблиц?
Это же сколько связей в голове надо держать.

Зачем что-то программировать если можно настроить?

[В гостях:))]

Цитата:

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

Зачем что-то программировать если можно настроить?

Если можно настроить - программировать незачем
С другой стороны, если нельзя настроить - придется либо умерить требования/поменять процесс, либо программировать))

[ALEG]

Цитата:

Сообщение от В гостях:))

В SAP многие из отраслевых решений ОЧЕНЬ сильно отличаются от стандартного ERP .

На CIO-Summit готов буду показать зоопарк САПов в одной взятой компании.

Лучше от этого сильно не становится. Я когда увидел прям чуть не прослезился это прям как зоопарк 1Сов в крупных русских компаниях...

[miklenew]

Цитата:

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

На CIO-Summit готов буду показать зоопарк САПов в одной взятой компании.
Лучше от этого сильно не становится. Я когда увидел прям чуть не прослезился это прям как зоопарк 1Сов в крупных русских компаниях...

Думаю "зоопарк" плохое слово, раз есть значит нуна.

[ALEG]

Цитата:

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

Думаю "зоопарк" плохое слово, раз есть значит нуна.

ага и баррикадная - плохое место, так как там место, которое называется "плохим словом" ))))))))))

[miklenew]

Цитата:

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

ага и баррикадная - плохое место, так как там место, которое называется "плохим словом" ))))))))))

Понятно. Это слово вы для чего-то заготовили.
Теперь его у вас не отнять.

[В гостях:))]

Цитата:

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

На CIO-Summit готов буду показать зоопарк САПов в одной взятой компании.

Лучше от этого сильно не становится. Я когда увидел прям чуть не прослезился это прям как зоопарк 1Сов в крупных русских компаниях...

Не надо, пожалуйста, передергивать. Не знаю конкретики по случаю, о котором вы говорите как о "зоопарке САПов", но скорее всего он никак не связан с наличием у САП двух с половиной десятков отраслевых решений. Более вероятно, что - с историческим наследием нескольких последовательных внедрений, организованной ради экономии на железе и быстродействии архитектуре и т.д. Либо - кривизной рук.

[ALEG]

Цитата:

Сообщение от В гостях:))

никак не связан с наличием у САП двух с половиной десятков отраслевых решений.

ага и с сотней партнерских решений )))

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

[В гостях:))]

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

[miklenew]

Цитата:

Сообщение от В гостях:))

Программисты стараются не писать программ, где задействовано 30 тысяч таблиц)) Вообще, обычно разработки ведутся под ТЗ консультанта, где четко описана задача.

Ну в Axapte тоже консультанты стараются чётко писать, но если программист стандартную архитектуру слабо представляет, то это может приветсти и к тому что задача будет долго делаться или плохо реализуется. Зависит от самой задачи.
Неужели чтоб стать программистом в Sap достаточно знать язык ABAP и всё.

Цитата:

Сообщение от В гостях:))

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

В одном? Это все так?