ВидыМоделей организационной мегамодели метода PraxOS

[ailev]

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

Comments

[vvagr]

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

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

[ailev]

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

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

[sergeyvi]

Ряд вопросов

[ailev]

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

[sergeyvi]

1. Я конечно, наверное еще не настоящий стратег (хотя уже в районе 5 лет работаю советником и заместителем директора по стратегии средней компании и с десяток стратегий для дочек написал, часть довольно успешно реализуется). Но тем не менее могу на себя примерить эту рубашку. И результат примерки - рукава коротки. А именно, для гениальности и озарения мне не нужен софт, а нужен карандаш, курвиметр, ексель и соответствующие карты. А вот для того, чтобы это озарение потом проверить, структурировать и превратить в нормальную дорожную карту, требуется уже софт, причем софт адекватный задачам. Сегодня используется что есть под рукой - MindManager, BPWin, Excel и Visio, причем, надеюсь понятно, что все это друг с другом стыкуется ручками, а все циферки постоянно таскаются из одной среды в другую

[ailev]

1. Наш жизненный опыт показывает, что стратегия обычно принимает форму "бизнес-плана". Мы же говорим, что у нас стратегия фиксируется в виде некоторого метода (жизненный цикл + практики + обоснования + описание продуктов и инструментов и т.д.), вдобавок должна быть поддержка trade-off (вариантов, развилок). Никакой "гениальности", всё шаблонно по форме. Но все-таки мы считаем, что содержательная нешаблонность должна присутствовать. Возможно, ваша содержательная нешаблонность была шаблонизирована именно вами -- и эти шаблоны стратегий дочек просто отражают нешаблонную стратегию холдинга

[emishanov]

"6. Архитектура IT-сервисов, включающая "единое информационное пространство". Это будет SOA плюс интеграция данных по ISO 15926." - во множестве организаций на SOA-интерфейсы приходится маленький процент всех взаимодействий информационных систем. ISO 15926 вообще почти нигде не применяется. Как планируется описывать эти случаи? Если предполагается описание модели TO BE - все равно, менять сто систем и тысячу интерфейсов одним махом никто не будет.

[kir_lis]

Приложение, даже если к нему нет "SOA-интерфейса", все равно оказывает ряд сервисов. В этом случае то, что называется сервисом, ближе к понятию функции, способности (capability), а не к понятию механизма доступа к функции, которое распространено в стандартах WS*.
Полагаю, что предназначение ВидаМодели #6 в том, чтобы указать на подобные "сервисы". Показать какие сервисы должны быть обеспечены для поддержания метода, какие сервисы могут быть обеспечены существующим и закупаемым ПО/оборудованием. Цель - обеспечить средство, с помощью которого можно снять зависимость между методом (требования бизнеса) и ПО/оборудованием (реализация требований). Такая модель поможет управлять соответствием между ними.
Основная проблема в настоящий момент - путаница с определением "сервиса". Даже создатели стандартов в области SOA еще ведут дискуссии этому поводу. Полагаю, что в PraxOS, будет выбрано такое определение и такая метамодель SOA, которые помогут достичь указанной цели.

[ailev]

Да.