Отраслевое решение - стереотип или нет?

[Vals]

Цитата:

Ага. Да. Скажем модификациям - нет!

Я тут недавно, пословицу перефразировал: "Семь раз настрой, один раз доработай (модифицируй)"

[slava09]

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

Я вам скажу как мне не по душе: внедрять чье-то отраслевое решение, логика которого выстрадана множеством не всегда квалифицированных консов и програмеров.

[EVGL]

Цитата:

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

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

Я вам скажу как мне не по душе: внедрять чье-то отраслевое решение, логика которого выстрадана множеством не всегда квалифицированных консов и програмеров.

Мы вот сделали два приложения для клиентов, а потом написали с нуля благодаря полученному опыту третье, отраслевое, в котором были только общие вещи. За счет компании, в рамках внутреннего проекта объемом порядка 2 человеко-лет. И внедрили на третьем клиенте, продав по стандартному прайс-листу. В чем проблема? На мой взгляд, без конца делать одно и то же чудовищно скучно.

[slava09]

Цитата:

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

Мы вот сделали два приложения для клиентов, а потом написали с нуля благодаря полученному опыту третье, отраслевое, в котором были только общие вещи. За счет компании, в рамках внутреннего проекта объемом порядка 2 человеко-лет. И внедрили на третьем клиенте, продав по стандартному прайс-листу. В чем проблема? На мой взгляд, без конца делать одно и тоже чудовищно скучно.

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

[Aleck]

Цитата:

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

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

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

[apanko]

Внедрял Retail от LS для NAV, товарный контур (бух в другой программе).

Процедура внедрения выглядела так:
1. Сходил на недельные курсы по аддону (как раз у партнера была группа - повезло).
2. Взял свои компьютеры и кассовые аппараты и поехал к внедренцам. Мне дали стул и стол, и показали человека которого можно "дергать". Примерно четыре дня там посидел, настроил репликацию и подключил ФР, сделал интерфейс для кассиров. Надергал не на дорого.

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

[Aleck]

Действительно "отраслевых решений" на рынке немного, гораздо больше маркетинговой шелухи, в которую попытались красиво обернуть какой-либо конкретный проект или, что еще хуже сборную солянку из нескольких проектов.
А нередко маркетинг опережает реальность и отраслевым решением обзывают то, что быстро сваяли на паре-тройке неудачных пресейлов.
Отраслевое решение, это не только код, но и планирование развития, единый проект, документация, курсы, поддержка и пр. Miсrosoft только в начале пути к отраслевым решениям (Industry Builder и ISV).
К сожалению в России сейчас порядка 90% именно шелухи, которая только рынок портит и клиентов дезинформирует.

[AlGol]

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

[MironovI]

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

[fed]

Вообще - я когда меня про вертикальные решения спрашивают, привожу следующую арифметику:
В Российской Федерации находится что-то порядка 30 пельменных заводов (думаю эта гипотетическая цифра близка к реальной). Представим себе, что мы сделали внедрения какого-то гипотетического продукта (Ax/Nav/1c не важно) на трех из этих заводов, накопив некоторый отраслевой опыт. Давайте рассмотрим экономический эффект от разработки отраслевого решения для пельменной промышленности. Для того чтобы собрать в одно целое три этих разных готовых решения, надо потратить заметное время. Надо выстроить некую обобщенную схему бизнес-процессов (убрав противоречия), задокументировать ее, разработать типовой план счетов, типовую учетную политику. Потом под все это дело надо частично разработать, частично собрать со старых проектов приложение. Потом надо это приложение тщательно тестировать (конечно на специально подготовленных тестовых данных, ведь заставить пользователей вбивать эти тестовые данные мы не можем - у нас просто нет пользователей). Тестировать нам тоже придется своими силами - поскольку пользователей у нас нет и делать ошибки или наваливатся на систему всем сразу никто за нас не будет. В общем - думаю я не сильно ошибусь, если скажу что затраты на разработку типового решения составят порядка 120-150% от стоимости одного внедрения.

Теперь давайте посмотрим на доходную часть:
У нас осталось не окученными 27 заводов. Представим что мы организуем обалденную маркетинговую компанию по их окучиванию (которая тоже денег стоит - эдак процентов в 40 от стоимости одного внедрения). Представим также, что наша маркетинговая машина отработала с немыслимой эффективностью и принесла нам 10 лидов, из которых мы 3 штуки довели до стадии продажи и продали.

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

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

По моим прикидкам, для того чтобы разработка 'правильного' вертикального решения окупилась, надо чтобы начальное количество проектов (на котором мы опыт копим) составляло бы где-то минимум 10-15, а потенциальный объем рынка - где-то порядка 400-700 внедрений. Если продолжать рассматривать наш пример, то для того чтобы разработка вертикального решения окупилась, надо в качестве целевого рынка рассматривать не Россию, а весь мир. Соответственно - сделать такое решение может только очень глобальный партнер (работающий во многих странах), причем это должен быть вертикально-интегрированный партнер, а не просто сеть франшиз, в лучшем случае слегка объединенных взаимным владением.

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

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

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

[miklenew]

Молодец fed. На своём опыте обосновал, что внедрять нужна не на основе готового решения, а на основе опыта, которым владеет команда.
Ибо копи-паст рулит.

[sukhanchik]

Цитата:

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

... надо чтобы начальное количество проектов (на котором мы опыт копим) составляло бы где-то минимум 10-15, а потенциальный объем рынка - где-то порядка 400-700 внедрений. ....

Вывод: Каждый партнер должен копить (в идеале) - некий опыт в виде несложных (затрагивающих мало объектов) модификаций, которые должен хорошо документировать и которые должны стопудово всем подходить и все сотрудники партнера стопудово должны знать эти модификации (т.к. они маленькие) - с т.з. функциональности.
Соответственно - приходя к очередному клиенту - продается (это даже решением назвать нельзя) некий "сервис-пак" (с) BOAL, в котором накоплен опыт партнера - и в который включено 99% востребованных клиентом модификаций (сразу скажу - модификации точно должны быть не отраслевыми). В идеале - этот "вымученный" "сервис-пак" - должен впоследствии выкупить Микрософт - если он ("сервис-пак") действительно ценен - и включить его в версию. В этом случае будет качественный скачок функциональности - и распространять этот "сервис-пак" будет международная компания .
При таком раскладе - затраты на разработку окупятся.

[fed]

Цитата:

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

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

Хороший бизнес план !
Если мне его принесут (как бы я финдир) я задам такие простые вопросы:
1. Предложите способ выделения из проектных модификаций тех самых "стопудово всем подходящих" и 99% востребованых.
2. Оцените стоимость интеграции модификаций, собранных в единый слой с разных проектов.
3. Подсчитайте стоимость их переноса на все выходящие обновления. (Раз в полгода примерно).
4. Подсчитайте экономический эффект от их применения.
5. Оцените риск того, что они будут несовместимыми с следующими версиями. (как показывает ситуация с DAX 2009 - риск высокий).

Жду твоей арифметики

[Serg]

to fed
По поводу бизнес плана, выделить такие доработки совсем не сложно и обосновать их экономическую целесообразность то же.

Пример.
Закрытие складе по «средней».
Всем известно, что Axapta закрывает с некой оговоркой, что стоимость расхода будет приближенной и чем выше растет цена текущем периоде, относительно предыдущего тем выше отклонение от стандартного метода расчета, которые делают бухгалтера и налоговые инспектора. С учетом текущего уровня инфляции можно прикинут отклонения.
Всем бухгалтерам и налоговым инспекторам известно, что метод закрытие по средней самый легкий и единственно возможный для проверки корректности его расчета. Для чего достаточно скинуть оборотку по складу в Excel и «протянуть» всем известные формулы.
Надеюсь многим должно быть известно, что излюбленный метод расчета себестоимости на производственных предприятиях с процессным типом про-ва это метод «средней» так как он позволяет упростить калькуляцию производственной себестоимости готовой продукции и полуфабрикатов. Помимо этого преимущество метод средней обладает положительной временной разницей относительно налога на прибыль.

Теперь осталось сделать небольшое заключение – что многие предприятия будут отказываются брать на себе практически 100% налоговый риск связанный с нарушениями правил ведения бухгалтерского учета, а именно использования метода средней в Аксапте.

Теперь о выгодах и потерях, по одному клиенту, Microsoft потерял как минимум порядка 1 млн $ на лицензиях в этом году.

Когда партнер Microsoft приведет в соответствие расчет средней к методу изложенному в правилах БУ и включит его в отраслевое решение, он займет лидирующее положение на рынке про-ных предприятий с процессным про-ва.

Так что поддерживать решения партнерам не просто выгодно, а иногда единственно возможный вариант оставаться на рынке.

[Raven Melancholic]

Цитата:

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

to fed
Когда партнер Microsoft приведет в соответствие расчет средней к методу изложенному в правилах БУ и включит его в отраслевое решение, он займет лидирующее положение на рынке про-ных предприятий с процессным про-ва.

Правда это уже будет не отраслевое, а универсальное решение.
Но Microsoft уже опередило партнёров, изменив в DAX2009 метод расчёта по средней

[fed]

Цитата:

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

to fed
По поводу бизнес плана, выделить такие доработки совсем не сложно и обосновать их экономическую целесообразность то же.

Расскажи как ?
Я просто неоднократно наблюдал попытки (причем у разных партнеров, а не только в том в котором я работал), собрать общий слой с доработками. Сценариев всего этого было два: Либо манагеры проектов разругивались на стадии утверждения списка доработок; Либо слой разрабатывался в отрыве от проектов (и их манагеров) и быстро становился бесполезным...
То есть - мое негативное отношение к всяким попыткам делать НЕПРОЕКТНЫЕ доработки сформировалось по итогам наступания на большое количество граблей...

Кстати - я так или иначе участвовал где-то в 20 проектах. Среднюю однажды переписывал. На остальных проектах - не понадобилось. Кто-то на FIFO жил, кто-то на партионной, кто-то довольствовался той средней, которая есть...

[sukhanchik]

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

Цитата:

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

Хороший бизнес план !
Если мне его принесут (как бы я финдир) я задам такие простые вопросы:
1. Предложите способ выделения из проектных модификаций тех самых "стопудово всем подходящих" и 99% востребованых.

Ну это я думаю не так сложно. Если есть какие-то модификации (в т.ч исправление багов), реализованные на N проектах (минимум 2) - то эти модификации - являются кандидатами на включение в "слой". Если модификации - являются общими более, чем на 5 проектах - то имеет смысл их включить в "слой". С большой долей вероятности - в 6-м проекте - модификация снова будет востребована.
И то - надо понимать - что 5 проектов по логистике не равны 6-му по финансам.
По сути - должен быть некий эксперт, который своим субъективным мнением должен определять "попадание в слой". Я пока не готов предложить объективную оценку .

Цитата:

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

2. Оцените стоимость интеграции модификаций, собранных в единый слой с разных проектов.

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

Цитата:

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

3. Подсчитайте стоимость их переноса на все выходящие обновления. (Раз в полгода примерно).

Вот тут вопрос ооочень философский. Обновление обновлению рознь. Сразу скажу - я не сторонник подъема на каждый сервис-пак (не то что на какие-то там хотфиксы). Лучше - через один. Да и независимо от наличия "базового слоя" - работы по анализу необходимости этого сервис-пака никто не отменял. Если отталкиваться от множества небольших модификаций, то:
а) на сервис-пак можно забить - вышестоящие слои перебьют его (очевидно - это решение должно приниматься очень ответственно)
б) на сервис-пак можно не торопиться пониматься (начинать проект с предыдущим СП)
в) на сервис-пак можно не подниматься, но перенести отдельные нужные модификации (если их мало)
г) на сервис-пак можно подняться.
Для каждого варианта надо просчитать экономический эффект - в зависимости от того - что поменяли в сервис-паке и от того - что лежит в "базовом слое" - что дешевле (что займет меньше человеко-часов и что меньше отразится на дальнейшем сопровождении).

Цитата:

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

4. Подсчитайте экономический эффект от их применения.

Это-то как раз просто. Классический пример - бага, тянущаяся еще с незапамятных времен. Исправляется - в одну строчку (я же говорил - модификации маленькие!). Но сколько времени потребутся чтобы вспомнить откуда растут ноги. Конечно - ради одной модификации - городить слой незачем. Но если их количество уже больше 10 - то почему бы и нет?
Опять-таки - считать надо в человеко-часах.

Цитата:

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

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

А вот тут-то могу позволить не согласиться. Кто сказал - что надо бежать всем на новую версию? Надо еще со старой разобраться. Да фиг с ней с поддержкой от Микрософт - она много дает? С 3-шкой - подписываться на обновления было невыгодно - 4-ка дешевле стоит, нежели 3-шка со всеми обновлениями.
Да, риск большой. Я считаю - что надо задумываться о новой версии - когда из старой все будет выжато по максимуму. Яркий пример - 4-ка. Ну и кому нужен переход с 3-шки на 4-ку - когда уже маячит 2009-я? Ну кроме конечно партнеров, консультантов и прочих лиц, которые с этого кормятся? Или же можно провести аналог - Win XP - Win Vista. А тут уже вполне можно смотреть на систему - как на новую - и заново ее внедрять. Уверен - что переход с 3-шки на 2009-ку будет стоить гораздо дешевле (раза в 2 точно), чем переход с 3-шки на 4-ку и с 4-ки на 2009-ку.

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

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

[miklenew]

Кто нибудь скажет что такое базовый слой, а то чё-то не пойму.

[fed]

В общем - по поводу базового слоя картина такая: Я очень часто слышу про экономию на стоимости внедрений, стоимости поддержки и т.п. Я заметно реже слышу про затраты на комплексирование, на перенос с версии на версию, на накладные расходы на поддержание организационной структуры ведения базового слоя. И я НИ РАЗУ НЕ видел нормального технико-экономического обоснования выгодности применения базового слоя. С нормальными финансовыми рассчетами и обоснованием ROI.
А раз такого обоснования нету - дык и повода для обсуждения нету. Раз нет оценок ни выручки (или сэкономленых затрат), ни рисков - значит нет повода для инвестиционного решения.

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

[fed]

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

Цитата:

возьмите, к примеру в 4-ке заказы на перемещение – какие там печатные формы накладных были? Правильно ни каких. А сколько надо – как минимум 2 Торг13 и ТТН, а по хорошему еще парочку. А как дела обстоят с синхронизацией складских аналитик? Опять ни как. А что делать, если по ходу маршрута склад назначения был изменен? Правильно ни чего не поделаешь. А где взять залоговые цены для транспортных компаний?