WJУ меня нет возражений по поводу правильности вашего подхода. Плюс/минус действие - но по сути это все правильно. Только вот работая с заказчиками мы столкнулись с такими реалиями:
1. далеко не все заказчики - групные предприятия. И очень даже далеко! Так что нужно уметь решать задачи и смотреть на мир и глазами среднего бизнеса в том числе
2. далеко-далеко не у всех есть развесистый штат ИТ-шников - это частично определяется пунктом 1, но бывают исключения и среди крупных компаний. Реально - это 1 сисадмин, 1-2 программера (обычно обслуживающие одинэсину или какой-то бухгалтерский софт). Ну и какой-нибудь энтузиаст полуайтишник-полуменеджер, который всю эту кашу заварит.
3. специально созданной для такой цели команды нет вообще ни у кого! Варианты:
- все передали в ИТ - получили технологический перекос, потерю интереса от бизнеса;
- топ-менеджмент взялся собственноручно за все. Но в силу недостатка времени все бросил и потянулось...
- инициативный менеджер/аналитик/кто-то еще взялся, все продумал, попробовал, просчитал... а начальство.... ну, мягко говоря, не оценило.
И потом им все это рассказать про EA. Они головами покивают - и пойдут искать где им помогут реально, а не будут учить жизни.

1. Вау, это ж какой такой мелкий и средний бизнес покупает решения по MDM и ESB?? а именно эти советы мелькали в ответах на топик. Что, неужто бесплатные использует?
2. Кто сказал что у мелкого и среднего бизнеса по 5 специализированных приложений используется на один БП??? А если 1 программер обслуживает 1С, то откуда проблема с разными базами и перекладыванием данных, которая освещалась в топике?? Мы что обсуждаем?
3. Очевидно, что если вы работете с SOHO сегментом рынка, то предлагайте для этого сегмента адекватные решения. Не следует приганять эскаватор, чтобы посадить куст смородины. Кроме этого, "реальности жизни" у каждого свои. У вас SOHO, у меня в текущий момент - корпоративный сегмент. А в топике обсуждаются решения преимущественно корпоративного сегмента. Так что приведенная вами "реалия жизни", когда EA предлагают SOHO или незрелым компаниям, вынужден отнести к категории фантазий, не имеющих ничего общего с действительностью.

АБSOHO мне кажется никто тут не имел в виду, а вот средний бизнес был и остается бааальшой проблемой. Задачи у него как у больших, а возможности - как у маленьких. В частности, лоскутная автоматизация и разные базы данных (о чем говорил топикстартер) для среднего бизнеса - обычное дело. Проблемы с разорванными бизнес-процессами - не надуманные. Ваш максималистский подход хорош, но явно не для них. В то же время с пользой применить ESB или BPMS в принципе не сложнее, чем СУБД, просто СУБД привычнее, а тут дело новое, непривычное. СУБД среднему бизнесу разрешается применять для каких-то собственных нужд?

1 программист 1С это средний бизнес??? Какие компании имеются ввиду, с какими ИТ бюджетами? Проблема то в чем у среднего бизнеса? Лоскутная автоматизация это ПРОБЛЕМА ДЛЯ БИЗНЕСА или для ИТ? Пока героическими усилиями двух разработчиков эти системы "среднего" бизнеса худо-бедно работают и их простой не приносит серьезных убытков бизнес не будет вкладывать деньги в облегчение жизни разработчиков и техподдержки :-). И тем более тратить деньги на ESB и BPMS ... как и впрочем на оптимизацию, консолидацию и т.п.
Забавно, с каких это пор, нормальные подходы являются максималистскими? И что самое интересное, ESB и BPMS это не максимализм, а вот получение внятной картины ИТ-архитектуры и ее анализ, это максимализм. Все по-нашему "накупим тулов они нам помогут"?

АБИ еще. Хорошо конечно когда есть кому и есть какие бюджеты осваивать. Тогда можно позвать Маккинзи и начать с иерархии процессов. Но во-первых, согласитесь, не все проекты такого рода заканичиваются удачно. А во-вторых, правило Парето никто не отменял: для того чтобы найти "бутылочное горлышко" - процессы откровенно плохо управляющиеся и откровенно слабые стыки между информационными системами - обычно сильно глубокий анализ не требуется. Например, мне известен кейс, в котором достаточно крупная американская компания выявила свои узкие места за несколько дней - экспертным опросом и мозговым штурмом. Мне лично такой подход нравится больше, чем описание 6-уровневой иерархии процессов. Если разобрать "по косточкам" и настроить всего один сквозной процесс, то от этого пользы будет больше, чем от всеобъемлющего анализа, не дошедшего до реализации. Пользы больше, трудоемкости и времени меньше.

А уж сколько проектов с использование ESB и прочих базвордов не принесло ожидаемого результата! Особенно когда горе-архитекторы, начитавшись маркетинговых лозунгов пихают тот же Нетвивер когда можно обойтись более дешевыми средствами ... Начинают делать интеграцию, без понимания на кой и почему и что с этого получиться. Уж поди поболе, чем недоведенных до конца проектов по EA :-). А если взять один процесс -- и его упорядочить, то на кой там ESB, MDM ??? Эти решения оправданы на уровне корпорации, а не на уровне одного процесса. А как известно из теории систем (вы же ее проходили в университете?), что что оптимально для одного элемента системы, не обязательно приводит к оптимальному результату для ВСЕЙ системы.

К тому же вопрос в том, какую задачу вы решаете ... если задача найти узкие места, то никто не спорит, что для небольшой компании не нужно звать Маккинзи. Я не понимаю антитеза-то в чем? Что вы хотите противопоставить утверждению о том, что:
1. В достаточно крупных компаниях, которые считают свои деньги и могут экономить на масштабах и для которых некоторые ИТ системы являются mission или business critical, построение модели и процессов поддержки EA (со сбалансированной детализацией) позволяет проводить анализ на основании которого можно а) оптимизировать затраты на БП б) повышать отдачу от ИТ.
2. Добиваться решения вышеуказанных результатов иными, не систематизированными способами можно, но это непредсказуемо и достаточно рискованно, особенно если учесть текучесть кадров, в т.ч. в ИТ.

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

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

cyx
Каковы минимальные "размер и степень зрелости" должны быть, чтобы затея имела смысл?

IMHO, минимально около 2-го уровня зрелости по модели COBIT. По размеру -- затраты на ИТ в пересчете на 1 сотрудника не менее 600 USD.

АБ byurПроблема то в чем у среднего бизнеса? Лоскутная автоматизация это ПРОБЛЕМА ДЛЯ БИЗНЕСА или для ИТ? В этом смысле средний бизнес ничем не отличается от крупного.


Так проблема для кого? Для ИТ или для бизнеса?

АБ byurЗабавно, с каких это пор, нормальные подходы являются максималистскими? Ну скажем, с тех пор, как появились agile методологии.

Остается дождаться Agile EA :-) ... (adaptive enterprise ?)

АБ byurЧто вы хотите противопоставить утверждению о том, что:
1. В достаточно крупных компаниях, которые считают свои деньги и могут экономить на масштабах и для которых некоторые ИТ системы являются mission или business critical, построение модели и процессов поддержки EA (со сбалансированной детализацией) позволяет проводить анализ на основании которого можно а) оптимизировать затраты на БП б) повышать отдачу от ИТ.
2. Добиваться решения вышеуказанных результатов иными, не систематизированными способами можно, но это непредсказуемо и достаточно рискованно, особенно если учесть текучесть кадров, в т.ч. в ИТ.
Много чего можно противопоставить, буквально каждому слову. Начиная с того, что крупные компании считают свои деньги :) и заканчивая тем, что из-за текучести кадров масштабные проекты предпочтительнее ограниченных. По-моему, все обстоит ровно наоборот.

Ну не нужно ж так ... там же ясно было сказано ".. компании, КОТОРЫЕ считают деньги".

АБПриведенный мной кейс - не исключение и не правило, а best practice из тренинга по BPM.

А вот тут стало интересно ... Чей это тренинг, можно узнать кто его читает? Если он в публичном доступе, можно ссылку?

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

Не исключаю такой возможности :-).

cyxС затратами на ИТ вовсе не понятно: это общий бюджет, бюджет проекта, к какому сроку привязан и т.п.?

В частности бюджет ИТ определяется на год.