Комментарии 118
Любое проектирование «большого и сложного» — должно базироваться на SE
Нет.
Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE?
Нет.
Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» – это тоже про SE
Нет.
Так как SE — это проектирование всего «большого и сложного», то по «определению» оно пересекается практически со всем известным из «Best Practice» & ххBOK, включая «SE & PMBOK», «SE & ITSM»
И тоже нет.
Если ЕА и ВРМ считаем алхимией, а SE не опровергает их подходы, а наоборот «дополняет», а зачастую «дублирует и повторяет»,
А из чего вы взяли, что системная инженерия "дополняет", "дублирует и повторяет" методы enterprise architecture и BPM?
то можно поставить под сомнение утверждение, что SE – это инженерная дисциплина.
А где это утверждение было сделано? Открываем первую попавшуюся википедию, читаем: "Systems engineering is an interdisciplinary field of engineering and engineering management". Все ровно как в ваших цитатах — междисциплинарный подход. В SEBoK то же самое, и делается упор на междисциплинарность. Вроде, никто не говорит, что это инженерная дисциплина. Так что вы ставите под сомнение утверждение, которого никто не делает.
Я проецирую эту мысль на наше время, как необходимость привлечения самих бизнес-пользователей «напрямую» к описанию и оптимизации своих бизнес-процессов без использования ИТ-специалистов (BPM-специалистов, ЕА-архитекторов и прочих алхимиков) и программистов.
К сожалению, опыт показывает, что большая часть бизнес-пользователей не обладает достаточной квалификацией. Причем я не говорю о BPM, EA или SE — существенная часть пользователей не способна самостоятельно корректно описать существующие процессы. Аналитика совершенно не зря является отдельным этапом.
Умеем лишь переводить «западную алхимию», перепродавать западную «комплектуху» и из нее лепить системы (комплексировать), что в ИТ
Вы опять по себе судите, да? Я в этом году как двадцать лет разрабатываю программные системы, и часть из них успешно применяется зарубежом. Так что я не знаю, как вы, а я вполне успешно имею дело с отечественной ИТ-индустрией, включая экспортную.
Да, верно, но только — пока эти направления: SE, ЕА, ВРМ — находятся на уровне развития «алхимия». Когда это станет реальной наукой и будут детальные и обоснованные (доказанные) и апробированные походы, то «следовать будет просто», даже начинающему.
Недоказуемое утверждение. Вы знакомы со спецификой гуманитарного знания? (и SE, и EA, и BPM неизбежно частью своей являются гуманитарными дисциплинами) Так вот, многие люди вообще не считают, что к гуманитарному знанию применим научный подход (та его часть, которая с экспериментами и доказательством). Есть множество устоявшихся и признанных отраслей гуманитарного знания, в которых непросто следовать начинающему. Да даже и в STEM есть куча таких отраслей, чего уж.
Проецируя на себя: мне намного больше дало изучение подходов к разработке военных систем (АСУ) и строительных ГОСТ и СНИП, которые я изучал 20 лет назад, чем современная литература примерно о том же, только в обертке «ЕА \ ВРМ» и с «маркетинговыми фишками», «цели бизнеса» и т.п.
Откройте оригинал, в котором написано следующее:
I cited earlier the half-life time of engineering details as being 15 years — half of the details you learn now will probably be useless to you in 15 years.
Так вот, в программировании, и вообще в IT это более чем верно; более того, я склонен думать, что сроки сейчас еще меньше.
Какой на Ваш взгляд ключевой документ по SE? [...] Это Схема деления изделия на составные части (ГОСТ 2.711-82). В этом и заключена детализация системы на элементы: изделия на отдельные под-изделия – составные части, которые в свою очередь являются изделиями (возможно даже изделиями типа «сложная система», некоторые покупные и т.п.).
И как этот "ключевой документ" отвечает на (а) вопросы управления жизненным циклом и (б) вопросы о целях и задачах?
Это должен быть предельно формализованный аппарат, позволяющий формализацию требований («хотелок»)
Сама природа бизнес-требований такова, что их формализация возможна только до определенной степени. И это как раз не инженерное знание.
Разрабатывать ТЗ на систему, у которой тысячи аналогов – какой смысл?
Гигантский, очевидно. Как вы предлагаете разрабатывать систему без ТЗ?
SE необходимо только для уникальных систем, которых еще ни у кого не было, т.к. они разрабатываются впервые.
Нет, SE необходима для всех (достаточно сложных) систем, потому что иначе вы не справитесь с реализацией. Напоминаю еще раз, SE — это дисциплина.
Со временем (видимо при коммунизме) основой построения систем будет заимствование действительно лучших решений
Осталось всего ничего — придумать критерий "лучшего решения".
SE необходима для всех (достаточно сложных) систем, потому что иначе вы не справитесь с реализацией
… я сам себе противоречу, конечно же. Нет, SE не необходима, потому что есть люди, которые справляются с проектами без всякой SE. Но все равно, необходимость SE на проекте определяется не уникальностью системы, а ее сложностью и навыками людей, участвующих в реализации.
Но все равно, необходимость SE на проекте определяется не уникальностью системы, а ее сложностью и навыками людей, участвующих в реализации.
Зачем SE, если нужно просто тупо повторить уже имеющийся прототип. Типовая система, понятно как она работает, проектные риски минимальные, есть на нее описание и т.п.
Фактически «серийное производство». Даже если завод-изготовитель (компания – разработчик) будет другой, то к чему ТЗ, проекты (эскиз, тех., раб.) и т.п.? Какой бы сложной система не была.
Типовые системы нужно тиражировать, а не «изобретать велосипед» в придачу с SE. Только уникальные нужно проектировать.
навыками людей, участвующих в реализации.
Это не причем. Промышленная разработка (конструкторское бюро, КБ, «фабрика» программистов и т.п.) даже высокотехнологичных изделий должна опираться не на «гениев», а на базовый уровень разработчиков.
Поэтому и предельно регламентируются все этапы конвейера разработки, чтобы получить гарантированное качество вне зависимости присутствия на конвейере (в КБ) «гения».
Зачем SE, если нужно просто тупо повторить уже имеющийся прототип.
Чтобы понять, что этот прототип применим к задаче. Чтобы понять, как его повторять. Чтобы внедрить и поддерживать.
Это не причем. Промышленная разработка (конструкторское бюро, КБ, «фабрика» программистов и т.п.) даже высокотехнологичных изделий должна опираться не на «гениев», а на базовый уровень разработчиков.
Вот именно поэтому "причем". Гениям не нужна системная инженерия, им не нужно планирование, им много что не нужно. Все эти вещи придумываются для того, чтобы декомпоновать задачу до уровня, доступного не-гениям.
Часть 1
Уважаемый lair, благодарю Вас за внимание к моей статье, однако позволю себе ответить только на те Ваши замечания, которые содержат ненулевую аргументацию.
Из прочтения литературы (и макулатуры тоже) по SE, ЕА, ВРМ и сопоставления сведений оттуда вычитанных. А у Вас откуда иные предположения?
Т.е. Вы утверждаете, что системная ИНЖЕНЕРИЯ – это не инженерная дисциплина?
Может быть «Междисциплинарный подход» — это когда системная инженерия претендует на то, что она работает со всеми инженерными специальностями? При этом она остается инженерной дисциплиной. А какой по-Вашему?
Конечно, только внешние консалтеры ей обладают. Мне это напоминает анекдот:
Про исследовательский бизнес есть анекдот. Около стада овец приземляется вертолет. Из вертолета выходит человек в костюме от Kiton и предлагает пастуху сделку: овца в обмен на точную информацию о поголовье стада. Пастух соглашается, человек подключает ноутбук к серверу NASA, получает необходимое спутниковое фото и печатает отчет на 150 страницах, из которого следует, что в стаде 3141 овца.
Забирает гонорар, но тут пастух делает ответное предложение: «Я точно называю твой бизнес, а ты отдаешь овцу назад».— «Идет».— «Ты — консультант».— «Как узнал?» — «Ты пришел, когда не звали, взял плату за то, что я и без тебя знаю, да и в моем деле ты ноль — отдавай мою собаку!»
Вы про такую аналитику?
За Вас я рад. Однако почти все мои соотечественники и я юзают западное ПО. Даже не смотря на огромные преференции, которые дало правительство отечественным разработчикам.
Есть наверно отдельные спец-форумы, где более точно покажут, что вокруг происходит, но мне казалось, что «невооруженным» глазом ХОРОШО видно окружающие нас отечественные программы, компьютеры и гаджеты.
Один и свежий пример. Купили телефончик Хонор, две недели поработал (настройки заводские, ничего не меняли), потом он перестал принимать пароль. Далее recovery boot. И всё: Game Over.
Далее — запрос аккаунта гугл (FRP) – который не принимается (типовая ситуация, судя по отзывам в инете). Про блокировку запроса аккаунта гугл (FRP) написано сотни статей, Прочитал 20 статей, попробовал 20 способов (перебор secret code – это только один из них) не сработали.
Случайно подошел пример, размещенный на совсем не ИТ-форуме.
Каждый из нас – потенциальная жертва подобной политики гугл. Все андороиды подвержены такой фитчи или багу или как еще это назвать. Уверен, что нечто подобное случается и с «огрызками».
Это что «технологическая независимость»? Отечественный софт? Это игла, на которой сидит каждый обладатель смартфона с андроид начиная с такой – то версии.
Кстати это тема как для «прокачки» в терминах SE, так и ЕА\НА (подсистемы home office, системная архитектура в НА).
Продолжение по второй части.
Уважаемый lair, благодарю Вас за внимание к моей статье, однако позволю себе ответить только на те Ваши замечания, которые содержат ненулевую аргументацию.
А из чего вы взяли, что системная инженерия «дополняет», «дублирует и повторяет» методы enterprise architecture и BPM?
Из прочтения литературы (и макулатуры тоже) по SE, ЕА, ВРМ и сопоставления сведений оттуда вычитанных. А у Вас откуда иные предположения?
А где это утверждение было сделано? Открываем первую попавшуюся википедию, читаем: «Systems engineering is an interdisciplinary field of engineering and engineering management». Все ровно как в ваших цитатах — междисциплинарный подход. В SEBoK то же самое, и делается упор на междисциплинарность. Вроде, никто не говорит, что это инженерная дисциплина. Так что вы ставите под сомнение утверждение, которого никто не делает.
Т.е. Вы утверждаете, что системная ИНЖЕНЕРИЯ – это не инженерная дисциплина?
Может быть «Междисциплинарный подход» — это когда системная инженерия претендует на то, что она работает со всеми инженерными специальностями? При этом она остается инженерной дисциплиной. А какой по-Вашему?
К сожалению, опыт показывает, что большая часть бизнес-пользователей не обладает достаточной квалификацией.
Конечно, только внешние консалтеры ей обладают. Мне это напоминает анекдот:
Про исследовательский бизнес есть анекдот. Около стада овец приземляется вертолет. Из вертолета выходит человек в костюме от Kiton и предлагает пастуху сделку: овца в обмен на точную информацию о поголовье стада. Пастух соглашается, человек подключает ноутбук к серверу NASA, получает необходимое спутниковое фото и печатает отчет на 150 страницах, из которого следует, что в стаде 3141 овца.
Забирает гонорар, но тут пастух делает ответное предложение: «Я точно называю твой бизнес, а ты отдаешь овцу назад».— «Идет».— «Ты — консультант».— «Как узнал?» — «Ты пришел, когда не звали, взял плату за то, что я и без тебя знаю, да и в моем деле ты ноль — отдавай мою собаку!»
Вы про такую аналитику?
Я в этом году как двадцать лет разрабатываю программные системы, и часть из них успешно применяется зарубежом. Так что я не знаю, как вы, а я вполне успешно имею дело с отечественной ИТ-индустрией, включая экспортную.
За Вас я рад. Однако почти все мои соотечественники и я юзают западное ПО. Даже не смотря на огромные преференции, которые дало правительство отечественным разработчикам.
Есть наверно отдельные спец-форумы, где более точно покажут, что вокруг происходит, но мне казалось, что «невооруженным» глазом ХОРОШО видно окружающие нас отечественные программы, компьютеры и гаджеты.
Один и свежий пример. Купили телефончик Хонор, две недели поработал (настройки заводские, ничего не меняли), потом он перестал принимать пароль. Далее recovery boot. И всё: Game Over.
Далее — запрос аккаунта гугл (FRP) – который не принимается (типовая ситуация, судя по отзывам в инете). Про блокировку запроса аккаунта гугл (FRP) написано сотни статей, Прочитал 20 статей, попробовал 20 способов (перебор secret code – это только один из них) не сработали.
Случайно подошел пример, размещенный на совсем не ИТ-форуме.
Каждый из нас – потенциальная жертва подобной политики гугл. Все андороиды подвержены такой фитчи или багу или как еще это назвать. Уверен, что нечто подобное случается и с «огрызками».
Это что «технологическая независимость»? Отечественный софт? Это игла, на которой сидит каждый обладатель смартфона с андроид начиная с такой – то версии.
Кстати это тема как для «прокачки» в терминах SE, так и ЕА\НА (подсистемы home office, системная архитектура в НА).
Продолжение по второй части.
те Ваши замечания, которые содержат ненулевую аргументацию.
Бремя доказательства лежит на утверждающем.
Из прочтения литературы (и макулатуры тоже) по SE, ЕА, ВРМ и сопоставления сведений оттуда вычитанных. А у Вас откуда иные предположения?
Из отсутствия подтверждающих цитат.
Т.е. Вы утверждаете, что системная ИНЖЕНЕРИЯ – это не инженерная дисциплина?
Да, именно так.
Может быть «Междисциплинарный подход» — это когда системная инженерия претендует на то, что она работает со всеми инженерными специальностями?
Нет. Открываем SEBoK: "Interdisciplinary approach governing the total technical and managerial effort required to" (выделение мое). Управленческие усилия — не инженерная дисциплина.
(С другой стороны, будем честными, я вот пошел искать определение инженерной дисциплины — и не нашел. Bad for me. Каким определением пользуетесь вы, говоря, что SE — не инженерная дисциплина?)
Конечно, только внешние консалтеры ей обладают.
Нет, ей обладают люди, которые занимаются анализом как дисциплиной, не важно, внешние они или внутренние.
Вы про такую аналитику?
Нет, я про качественно проведенный бизнес-анализ.
Даже не смотря на огромные преференции, которые дало правительство отечественным разработчикам.
… а это какие, если не секрет?
Каждый из нас – потенциальная жертва подобной политики гугл.
Не используйте продукты гугл.
Это что «технологическая независимость»?
А я нигде не говорил про технологическую независимость. Я в нее и не верю, собственно говоря.
Бремя доказательства лежит на утверждающем.
В данной ситуации: в статье приведены аргументы, Вы же на них просто заявили: «Нет», «И тоже нет», не представив аргументацию по этим «нет». Поэтому бремя переложено на Вас.
Из отсутствия подтверждающих цитат.
В самом начале:
Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» – это тоже про SE, а в стандартах SE – постоянно говорится о «моделировании» и «процессах».
Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE? В стандартах SE часто употребляется и «предприятие» и «архитектура». Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
Это не цитаты, но смысл дают ясный.
Вы действительно считаете, что в SE нет про моделирование процессов и архитектуру? В том же: ISO/IEC 15288 про это говорится.
Управленческие усилия — не инженерная дисциплина.
Они есть во всех процессах, системах и т.п. Это очень общий термин. Управление – это вообще нечто, присутствующее во всем и везде (типа «святого духа»). В любой «Best Practice» — о нем много и разного сказано.
Когда говорят «системная инженерия» — впрочем, как и любая «инженерия» — я это отношу «автоматом» к «инженерная дисциплина».
… а это какие, если не секрет?
На память не помню, но много попадалось в заголовках новостей: всякие там реестры отечественных разработчиков софта, гранты куда-то и т.п. Если не найдете, скажите – погуглю.
Не используйте продукты гугл.
Ну очень смешно. Рад бы не использовать. Я же говорю, что гугл и механизм запроса аккаунта гугл (FRP) – зашиты в КАЖДЫЙ телефон с андроид:
С появлением системы Android 5.1 Lollipop у пользователей появились не только новые полезные функции, но и откровенно тупящие «фичи». К примеру, Google FRP Lock, он же «защита от сброса настроек», суть которой заключается в защите телефона от злоумышленников, которые решили обойти блокировку смартфона путём сброса настроек.
После сброса настроек пользователь обязан войти в Google аккаунт, к которому был привязан этот телефон, но очень часто бывает, что телефон просто не принимает правильный аккаунт и пароль.
А я нигде не говорил про технологическую независимость. Я в нее и не верю, собственно говоря.
А вот наши предки не только верили, но и добились этой независимости. И всё в стране было отечественное, т.е. сделанное «собственными руками». Сейчас это в прошлом. Прежде всего, потому, что давно нет веры. Но одной веры (если она и вернется) будет явно не достаточно.
В данной ситуации: в статье приведены аргументы
Да нет же. В статье приведены утверждения, которые ничем не подтверждены. Возьмем первое же:
Любое проектирование «большого и сложного» — должно базироваться на SE
Это просто ваше высказывание, чем оно обосновано?
Это не цитаты, но смысл дают ясный.
Благодаря тому, что это не цитаты, они дают смысл того, что вы думаете, но нет никакого подтверждения, что так же думают методологи.
Вы действительно считаете, что в SE нет про моделирование процессов и архитектуру?
То, что в SE есть что-то про архитектуру и модели, не означает, что SE занимается тем же, что BPM и EA.
управление – это вообще нечто, присутствующее во всем и везде (типа «святого духа»).
Нет. В расчете подъемной силы крыла нет никакого управления.
Когда говорят «системная инженерия» — впрочем, как и любая «инженерия» — я это отношу «автоматом» к «инженерная дисциплина».
… и начинаете спорить с собственным же утверждением.
Но вернемся к вопросу: что такое "инженерная дисциплина"? Каково ее определение? Какими свойствами она обладает?
На память не помню, но много попадалось в заголовках новостей: всякие там реестры отечественных разработчиков софта, гранты куда-то и т.п. Если не найдете, скажите – погуглю.
Не нашел.
Ну очень смешно. Рад бы не использовать. Я же говорю, что гугл и механизм запроса аккаунта гугл (FRP) – зашиты в КАЖДЫЙ телефон с андроид:
Не используйте андроид.
А вот наши предки не только верили, но и добились этой независимости. И всё в стране было отечественное, т.е. сделанное «собственными руками». Сейчас это в прошлом.
Не вижу смысла спорить о прошлом; а в настоящем этой независимости нет. И это одна из причин, почему я не верю в ее достижимость.
«Любое проектирование «большого и сложного» — должно базироваться на SE»
Это просто ваше высказывание, чем оно обосновано?
Например, также думают Авторы: В. К. Батоврин. Ф. И. Голдберг. А. В. Александров.
Системная инженерия, или системотехника — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем
Множество других авторов также подчеркивает, что по SE хоть и можно строить простые системы, но задумалась она именно под проектирование «сложных» и «больших».
Странно, что это вызывает у Вас вопросы.
То, что в SE есть что-то про архитектуру и модели, не означает, что SE занимается тем же, что BPM и EA.
Приводил несколько ссылок:
Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
Есть рассказы (байки) КАК АРХИТЕКТУРА ПРЕДПРИЯТИЯ ДОПОЛНЯЕТ СИСТЕМНУЮ ИНЖЕНЕРИЮ
Пересечение SE с ЕА выделяют в отдельное направление: ESE
Если недостаточно, то набираем в гугл: «Systems Engineering» «Enterprise Architecture».
Нет. В расчете подъемной силы крыла нет никакого управления.
Сам расчет уже предполагает, что нужен для управления.
… и начинаете спорить с собственным же утверждением.
Но вернемся к вопросу: что такое «инженерная дисциплина»? Каково ее определение? Какими свойствами она обладает?
БСЭ: www.ngpedia.ru/id6004p1.html
studopedia.ru/4_14767_programmnaya-inzheneriya-kak-inzhenernaya-distsiplina.html
Не используйте андроид.
Снова смеетесь? Вы в магазин телефонов заходили? На полке лежат только телефоны с андроид и пара «огрызков».
У покупателя нет выбора. Точнее есть из «плохо» и «очень плохо».
Я не против ОС андроид — я против того, чтобы гугл ставил обязательным условием использования телефона (причем как «звонилка») — условие использования сервисов гугл.
Если завтра огрызок и гугл попадут в список запретных в стране организаций, то мобильная связь в стране рухнет. Хотя гугл и не производит телефоны.
Даже без такого списка ситуация уже доведена до абсурда: гугл заблокирует Вашу учетку и не даст создать новую и Вы останетесь не только без приложений, но теперь уже и без связи: телефон даже не звонит, т.к. требует для этого учетку гугл.
Завтра каждый кран подачи воды в квартиру будет содержать «клапан гугл», требующий «активную учетку», и когда учетку заблокируют, то все погибнут от жажды. Это тем, кто «не верит в технологическую независимость».
Например, также думают Авторы: В. К. Батоврин. Ф. И. Голдберг. А. В. Александров.
Системная инженерия, или системотехника — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем
Не же, не думают. В определении написано: "дисциплина, которая изучает". Это не значит, что изучаемое должно строиться на этой дисциплине.
Множество других авторов также подчеркивает, что по SE хоть и можно строить простые системы, но задумалась она именно под проектирование «сложных» и «больших».
То, что SE задумывалась под проектирование A, не означает, что для проектирования A обязательно использовать SE.
Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
Это отдельное направление. И там все еще не сказано, что это то же самое, что BPM или EA. Это просто применение принципов SE к предприятию.
Сам расчет уже предполагает, что нужен для управления.
Это не отменяет того, что в расчет управление не входит.
www.ngpedia.ru/id6004p1.html
Эта ссылка у меня не открывается.
studopedia.ru/4_14767_programmnaya-inzheneriya-kak-inzhenernaya-distsiplina.html
По этой ссылке сказано, что программная инженерия — это инженерная дисциплина, но нет определения инженерной дисциплины.
На полке лежат только телефоны с андроид и пара «огрызков».
Это немножко неправда.
Я не против ОС андроид — я против того, чтобы гугл ставил обязательным условием использования телефона (причем как «звонилка») — условие использования сервисов гугл.
Против — не используйте телефоны с ОС Андроид. Вот вам звонилка.
Завтра каждый кран подачи воды в квартиру будет содержать «клапан гугл», требующий «активную учетку», и когда учетку заблокируют, то все погибнут от жажды.
Нет, не будет.
Это тем, кто «не верит в технологическую независимость».
А технологическая независимость ничего не изменит. Просто блокировка учетки будет не у Гугла, а у Яндекса.
Эта ссылка у меня не открывается.
Да, перестала работать. Вот такие wiki.
Это была: Большая энциклопедия нефти и газа, а уже там «инженерная дисциплина».
Я бы законом запретил подобную привязку «телефона», но видимо без нее «никак».
Точнее блокировка учетки будет не у гугла или яндекса, а у соответствующего правительства, которое их контролирует.
Остальные ответы позже.
Да, перестала работать. Вот такие wiki.
Это была: Большая энциклопедия нефти и газа, а уже там «инженерная дисциплина».
Просто блокировка учетки будет не у Гугла, а у Яндекса
Я бы законом запретил подобную привязку «телефона», но видимо без нее «никак».
Точнее блокировка учетки будет не у гугла или яндекса, а у соответствующего правительства, которое их контролирует.
Остальные ответы позже.
Да, перестала работать. Вот такие wiki.
Лишний пример, почему надо не просто кидать ссылки, а приводить атрибутированные цитаты.
(на StackOverflow, скажем, просто не пропускают ответы, состоящие только из ссылки)
Я бы законом запретил подобную привязку «телефона», но видимо без нее «никак».
Еще один любитель законно введенных монополий.
Точнее блокировка учетки будет не у гугла или яндекса, а у соответствующего правительства, которое их контролирует.
Спасибо, я как-нибудь без этого обойдусь.
С андроидом — уже точно «не обойдусь».
Так нас с Вами никто спрашивать и не будет, ни гугл, ни яндекс, ни их кураторы. Блокировки будут (уже есть, как я показал выше) без нашего согласия.
Так нас с Вами никто спрашивать и не будет, ни гугл, ни яндекс, ни их кураторы. Блокировки будут (уже есть, как я показал выше) без нашего согласия.
С андроидом — уже точно «не обойдусь».
Именно поэтому если я хочу независимости от чужих решений, мне андроид не подойдет.
Блокировки будут (уже есть, как я показал выше) без нашего согласия.
… и чем вам поможет "технологическая независимость", кроме того, кто будет вас блокировать?
Именно поэтому если я хочу независимости от чужих решений, мне андроид не подойдет.
Введут контроль на все телефон-ОС, а неподконтрольные запретят. По аналогии с ТОР.
… и чем вам поможет «технологическая независимость», кроме того, кто будет вас блокировать?
У соотечественников рычагов давлении на яндекс и его куратора, все же несколько больше чем на гугл и его куратора. Разве нет?
Это отдельное направление. И там все еще не сказано, что это то же самое, что BPM или EA. Это просто применение принципов SE к предприятию.
«Это просто применение принципов SE к предприятию» — и означает «то же самое», применительно к «предприятию».
Про «перепевы» ЕА и SE:
Если читать wiki Архитектура системы
то текст по SE читается, как будто про ЕА.
А если открыть ISO/IEC/IEEE 42010-2011 ОПИСАНИЕ АРХИТЕКТУРЫ Systems and software engineering. Architecture description
то там (в стандарте на SE) рассказывается про ЕА:
4.5 Структуры архитектуры и языки описания архитектуры
Примерами структуры архитектуры в терминах настоящего стандарта являются: структура архитектуры Захмана для информационных систем [44], структура архитектуры британского Министерства обороны [27], структура архитектуры открытых групп (TOGAF) [41], модель представления Крухтена «4+1» [23], четыре метода представлений Сименса [10], эталонная модель для открытой распределенной обработки (RM-ODP) [ИСО/МЭК 10746] и обобщенная эталонная архитектура предприятия (GERA) [ISO 15704].
«Это просто применение принципов SE к предприятию» — и означает «то же самое», применительно к «предприятию».
"То же самое" — в смысле, SE. Не "то же самое, что и BPM".
Если читать wiki Архитектура системы то текст по SE читается, как будто про ЕА.
Если вам что-то читается одинаково, это еще не значит, что это одинаково.
то там (в стандарте на SE) рассказывается про ЕА:
И снова нет. Там говорится, что приведенные модели являются примерами структуры архитектуры так, как ее (структуру) понимает этот ISO. Это снова не означает, что SE занимается тем же, что и EA, это означает, что пересекается их инструментарий.
(я, кстати, вообще не уверен, что это "стандарт на SE", слишком уж заголовок расплывчатый)
В чем пересечение ЕА и SE (желательно список)?
Что значит:
Что значит:
пересекается их инструментарий.
В чем пересечение ЕА и SE (желательно список)?
Это не ко мне вопрос. Вы начали утверждать, что EA и SE — это одно и то же, вам и приводить список "одного и того же" (два непустых множества не могут быть идентичными, если у них нет пересечений).
Если верить приведенному вами стандарту, то некоторые из методологий EA используют те же архитектурные диаграммы, что и какая-то методология SE.
Что значит: "пересекается их инструментарий"
Это значит, что какие-то из инструментов, используемых SE, используются и в EA.
Это значит, что какие-то из инструментов,
Что в данном случае, Вы понимаете под «инструментом»?
Желательно с конкретными примерами.
Например, нотацию для архитектурных диаграм (я не говорю, что EA и SE действительно используют общую нотацию, но если бы использовали — это был бы такой инструмент).
Но какое это имеет значение?
Например, нотацию для архитектурных диаграм
Можно еще три — четыре примера
Но какое это имеет значение?
Нужно понимать, что Вы имеете ввиду, т.к. мне кажется, что часто наш диалог напоминает «глухого со слепым».
Если Вы так активно взялись за критику (за что Вам спасибо), то на вопросы по конкретике к SE, ЕА, ВРМ как то странно от Вас слышать:
Это не ко мне вопрос.
Можно еще три — четыре примера
Нет, сходу в голову не приходит.
Нужно понимать, что Вы имеете ввиду,
А зачем? Что это изменит в аргументации?
как то странно от Вас слышать:
А мне странно от вас слышать просьбы доказать ваши тезисы.
> Нужно понимать, что Вы имеете ввиду,
А зачем? Что это изменит в аргументации?
Пытаюсь понять Вашу позицию. Понял, что она всегда противоположна моей. Это нормально. Но какая она конкретно — понять не могу. Поэтому и спрашиваю «конкретно».
Если есть конкретная позиция – есть смысл спорить, а если нет, то, видимо, – нет.
Утверждаю, что «пересекаются» – в ответ:
«И снова нет. … это означает, что пересекается их инструментарий.»
Что за «инструменты»? – «Нет, сходу в голову не приходит.»
Меня не устаревают ответы типа: «Если вам что-то читается одинаково, это еще не значит, что это одинаково».
Нужна конкретика. На отвлеченные темы (офтопики) — у Вас конкретика есть (примеры зодчества и т.п.), то теме SE\EA\BPM — нет.
Может быть, есть смысл вначале вникнуть в тему и сформировать собственное мнение, а потом уже обсуждать по существу?
Пытаюсь понять Вашу позицию. Понял, что она всегда противоположна моей. Это нормально. Но какая она конкретно — понять не могу.
А она очень проста (и я ее озвучивал): вы делаете много расплывчатых утверждений, которые не основаны ни на чем, кроме вашего собственного суждения.
Утверждаю, что «пересекаются»
В том-то и дело, что вы утверждаете совсем не это. Вы утверждаете, дословно: "там (в стандарте на SE) рассказывается про ЕА".
Меня не устаревают ответы типа: «Если вам что-то читается одинаково, это еще не значит, что это одинаково».
Ну так не приводите аргументы типа "текст по SE читается, как будто про ЕА", не приводя ни одного из текстов.
Нужна конкретика.
Прекрасно. Начните с себя. Вы говорите "можно поставить под сомнение утверждение, что SE – это инженерная дисциплина", но не говорите ни что такое "инжереная дисциплина" (вы до сих пор не привели определения), ни кто утверждает, что SE – это инженерная дисциплина. Более того, дальше вы пишете, что это ваше утверждение ("Когда говорят «системная инженерия» — впрочем, как и любая «инженерия» — я это отношу «автоматом» к «инженерная дисциплина»").
Ответьте, пожалуйста, прямо: У Вас есть собственная конкретная позиция по SE\EA\ВРМ?
Если есть, то какая?
То, что она уже «по определению» противоположна моей, — это понятно. Не понятно, какая она конкретно.
Если есть, то какая?
То, что она уже «по определению» противоположна моей, — это понятно. Не понятно, какая она конкретно.
Ответьте, пожалуйста, прямо: У Вас есть собственная конкретная позиция по SE\EA\ВРМ?
По BPM — нет. По SE/EA — да, есть: что это существующие дисциплины, которые, будучи разумно примененными, приносят пользу.
(заметим в скобках, что вы снова потребовали от меня конкретики, полностью проигнорировав конкретные вопросы)
По BPM — нет. По SE/EA — да, есть: что это существующие дисциплины, которые, будучи разумно примененными, приносят пользу.
Яды, «которые, будучи разумно примененными,» ТОЖЕ «приносят пользу.»
Конкретная позиция есть по SE/EA\ВРМ?
Хотя бы чем BPM отличается от EA?
Конкретная позиция есть по SE/EA\ВРМ?
Я ее уже озвучил.
Хотя бы чем BPM отличается от EA?
Я же сказал, что по BPM у меня позиции нет.
Я же сказал, что по BPM у меня позиции нет.
Выходит, что по ЕА – «есть», а по ВРМ – «нет».
Только ВРМ – это во многом (более половины) тот же ЕА.
Снова «нет»?
Выходит, что по ЕА – «есть», а по ВРМ – «нет».
Ну да, а что вас удивляет?
Только ВРМ – это во многом (более половины) тот же ЕА.
Это ваше утверждение, которому у меня нет никаких оснований доверять. Но даже если бы оно было верным, что это меняет?
Как минимум, то, что это «перепевы» одного «и тогож» (про отнесение их к алхимии – даже не указываю).
С чем, насколько я понял – Вы не согласны.
Хотя я уже потерялся, с чем согласны, а чем нет (знаю точно, что не с моим мнением, поэтому как-нибудь его поменяю под Ваш ответ, для подтверждения своей гипотезы).
Вы же утверждали о всех трех дисциплинах.
Простите, но по этой ветке я «пас». Если человек хочет донести свою мысль (когда его просят), то когда он видит, что его не понимают, он напишет «много букв», как это делаю я и другие участники обсуждения в этом топике.
С чем, насколько я понял – Вы не согласны.
Хотя я уже потерялся, с чем согласны, а чем нет (знаю точно, что не с моим мнением, поэтому как-нибудь его поменяю под Ваш ответ, для подтверждения своей гипотезы).
А из чего вы взяли, что системная инженерия «дополняет», «дублирует и повторяет» методы enterprise architecture и BPM?
… (и SE, и EA, и BPM неизбежно частью своей являются гуманитарными дисциплинами)
…
Вы же утверждали о всех трех дисциплинах.
Простите, но по этой ветке я «пас». Если человек хочет донести свою мысль (когда его просят), то когда он видит, что его не понимают, он напишет «много букв», как это делаю я и другие участники обсуждения в этом топике.
Как минимум, то, что это «перепевы» одного «и тогож»
Это никак не вытекает из моих слов. Если вы так считаете — это ваше право, но я могу иметь мнение об одном, и не иметь мнения о другом.
С чем, насколько я понял – Вы не согласны.
Я не согласен с вашим утверждением, что "это перепевы одного и того же", потому что приведенные вами аргументы меня не убеждают.
Вы же утверждали о всех трех дисциплинах.
Я утверждал, что все они частично являются гуманитарными. Продолжаю так считать, да.
Если человек хочет донести свою мысль (когда его просят), то когда он видит, что его не понимают, он напишет «много букв», как это делаю я и другие участники обсуждения в этом топике.
Во-первых, мои "много букв" были раньше, и вы их прекрасно проигнорировали. Во-вторых, я в среднем не считаю, что "много букв" облегчает понимание; зачастую, наоборот.
Часть 2
Для меня это новость.
я все же про то, что можно проверить опытным путем и мне казалось, что все законы и утверждения SE, EA, BPM могут (должны) быть апробированы. При условии, что SE, EA, BPM — устойчиво «встанут» на путь науки и инженерии.
Я привел личный опыт. Для меня именно те сведения были более значимыми, чем «современная литература». Правда, читал избирательно — далеко не все, но ее появилось «очень много», как стог сена (может иголки не заметил).
Повторюсь: с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
А им намного больше 15 лет.
На эти вопросы – никак, но это все равно ключевой «документ – артефакт» в SE.
Хорошо, а Ваше мнение – какой документ самый ключевой?
Да, большинство систем должны просто тиражироваться. Даже если есть особенность, то не нужно составлять 50 страниц абстрактных требований, а нужно указать два предложения, в которых будет сказано: чем система должна отличаться от существующего аналога или типовой конфигурации.
ОЧЕНЬ мало людей, кто может составить качественное ТЗ. Почти все ТЗ – это «филькина грамота» и они «работают» в интересах поставщика, а не заказчика: лишь на том принципе, что заказчик никогда грамотное ТЗ не составит. Тогда разработчик говорит «сам дурак» и требует деньги на доработку. Хотя изначально понимает, что нельзя никак сделать качественное ТЗ.
Чтобы составить грамотное ТЗ – нужно большие трудозатраты (причем периодические и поэтапные уточнения). Мне попадались оценки, что грамотное ТЗ «стоит» не менее 30% общих трудозатрат на проект.
Иначе получается типовой сценарий, смотрите картинку Проект «Тарзанка»
Мне казалось, что это уже понятно многим. Сейчас иногда встречается договоренность, что договор предусматривает 30% доработок по уточнению ТЗ при фиксированной стоимости работ.
ТЗ – это исключительная ситуация, оно только для проектирования принципиально новых систем. Но это видимо лишь в будущем, пока такие простые истины еще не очевидны и победа за «управленческими уловками» подрядчиков.
Отвечать лучше отдельным постом, уверен, что это будет отдельная дискуссия.
Вот именно. Я уже про этот «трюк» указывал в статье.
Под вывеской «Best Practice» — часто «подсовывают» совсем не практику (не публикуют ее, все NDA и ДСП), и совсем не понятно почему она «лучшая». Это вопрос к SE, ЕА, ВРМ.
и SE, и EA, и BPM неизбежно частью своей являются гуманитарными дисциплинами)
Для меня это новость.
Так вот, многие люди вообще не считают, что к гуманитарному знанию применим научный подход (та его часть, которая с экспериментами и доказательством).
я все же про то, что можно проверить опытным путем и мне казалось, что все законы и утверждения SE, EA, BPM могут (должны) быть апробированы. При условии, что SE, EA, BPM — устойчиво «встанут» на путь науки и инженерии.
Так вот, в программировании, и вообще в IT это более чем верно; более того, я склонен думать, что сроки сейчас еще меньше.
Я привел личный опыт. Для меня именно те сведения были более значимыми, чем «современная литература». Правда, читал избирательно — далеко не все, но ее появилось «очень много», как стог сена (может иголки не заметил).
Повторюсь: с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
А им намного больше 15 лет.
И как этот «ключевой документ» отвечает на (а) вопросы управления жизненным циклом и (б) вопросы о целях и задачах?
На эти вопросы – никак, но это все равно ключевой «документ – артефакт» в SE.
Хорошо, а Ваше мнение – какой документ самый ключевой?
Гигантский, очевидно. Как вы предлагаете разрабатывать систему без ТЗ?
Да, большинство систем должны просто тиражироваться. Даже если есть особенность, то не нужно составлять 50 страниц абстрактных требований, а нужно указать два предложения, в которых будет сказано: чем система должна отличаться от существующего аналога или типовой конфигурации.
ОЧЕНЬ мало людей, кто может составить качественное ТЗ. Почти все ТЗ – это «филькина грамота» и они «работают» в интересах поставщика, а не заказчика: лишь на том принципе, что заказчик никогда грамотное ТЗ не составит. Тогда разработчик говорит «сам дурак» и требует деньги на доработку. Хотя изначально понимает, что нельзя никак сделать качественное ТЗ.
Чтобы составить грамотное ТЗ – нужно большие трудозатраты (причем периодические и поэтапные уточнения). Мне попадались оценки, что грамотное ТЗ «стоит» не менее 30% общих трудозатрат на проект.
Иначе получается типовой сценарий, смотрите картинку Проект «Тарзанка»
Мне казалось, что это уже понятно многим. Сейчас иногда встречается договоренность, что договор предусматривает 30% доработок по уточнению ТЗ при фиксированной стоимости работ.
ТЗ – это исключительная ситуация, оно только для проектирования принципиально новых систем. Но это видимо лишь в будущем, пока такие простые истины еще не очевидны и победа за «управленческими уловками» подрядчиков.
Отвечать лучше отдельным постом, уверен, что это будет отдельная дискуссия.
Осталось всего ничего — придумать критерий «лучшего решения».
Вот именно. Я уже про этот «трюк» указывал в статье.
Под вывеской «Best Practice» — часто «подсовывают» совсем не практику (не публикуют ее, все NDA и ДСП), и совсем не понятно почему она «лучшая». Это вопрос к SE, ЕА, ВРМ.
Для меня это новость.
Я заметил.
я все же про то, что можно проверить опытным путем
Ну вот часть гуманитарного знания нельзя проверить опытным путем.
Повторюсь: с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
А им намного больше 15 лет.
А это engineering details? Не думаю.
Я привел личный опыт.
Опыт против опыта. 20 лет назад я сидел на платформе, которой сейчас не существует, разрабатывая программы на языке, который сейчас развивается совсем в другую сторону. Никакие детали моего тогдашнего опыта (в отличие от принципов) для меня сейчас неприменимы.
Да, большинство систем должны просто тиражироваться.
Чтобы тиражироваться, все равно нужно ТЗ.
а нужно указать два предложения, в которых будет сказано: чем система должна отличаться от существующего аналога или типовой конфигурации.
… и потом 50 страниц анализа, как эти отличия не конфликтуют с существующей системой.
Чтобы составить грамотное ТЗ – нужно большие трудозатраты
Да, это так. Но это никак не значит, что ТЗ не нужно.
ТЗ – это исключительная ситуация, оно только для проектирования принципиально новых систем
Вы не можете внедрить систему без ТЗ. Ну заменится у вас ТЗ на разработку на ТЗ на внедрение — что, легче станет?
Вот именно. Я уже про этот «трюк» указывал в статье.
И сам же его и применил.
Вы не можете внедрить систему без ТЗ.
Можно сослаться ровно также: внедрить «точно также» как «там — то» (конкретно где, например, в своей дочерней компании).
Обсуждение подходов к ТЗ и проблем «управления требованиями» — заслуживает отдельной статьи.
И сам же его и применил.
Я критиковал подмену «Лучших практик» (псевдо-лучшие практики), т.е. когда сегодня это крылатое выражение применяется к «непрактикам» (не опубликованным и вообще неизвестно внедренным ли) и «нелучшим» или «лучшим», но с позиций «управленческая уловка», «маркетинговый обман», «лживый пиар» и т.п.
Когда я говорю о правильных «Best Practice», то я и подчеркиваю, что первый критерий — это опубликованность: содержание рабочего проекта или возможность доступа к самой конечной системе или другие доказательства «практики». Иначе разговоры уходят в плоскость мифологии.
Разобраться бы вначале с первым, а то приходится сравнивать «нули с нулями».
Можно сослаться ровно также:
Это означает, что вы будете использовать ТЗ, написанно "там-то". А перед этим вам надо доказать его применимость (это я говорю как человек, который несколько раз делал реализации "точно так же, как", а потом выяснялось, что они неприменимы).
Когда я говорю о правильных «Best Practice», то я и подчеркиваю, что первый критерий — это опубликованность: содержание рабочего проекта или возможность доступа к самой конечной системе или другие доказательства «практики». Иначе разговоры уходят в плоскость мифологии.
Разобраться бы вначале с первым, а то приходится сравнивать «нули с нулями».
Нет смысла разбираться с первым, если нет второго. Вот опубликуют люди десять практик — как вы будете их сравнивать на лучшесть? Пока нет этого ответа, непонятно, зачем публиковаться.
Это означает, что вы будете использовать ТЗ, написанно «там-то». А перед этим вам надо доказать его применимость (это я говорю как человек, который несколько раз делал реализации «точно так же, как», а потом выяснялось, что они неприменимы).
Одна из ключевых мыслей, которую пытаюсь донести через «ТЗ»: не нужно перекладывать внутренние риски подрядчика на заказчика.
Если заказчик ткнул на аналог и сказал «хочу такую же», то это уже риск подрядчика, что две системы не совпадут.
Здесь еще будет играть фактор, что все стандартное и типовое будет на порядок дешевле и надежнее нетипового и уникального.
Нет смысла разбираться с первым, если нет второго. Вот опубликуют люди десять практик — как вы будете их сравнивать на лучшесть? Пока нет этого ответа, непонятно, зачем публиковаться.
Когда опубликуют, то желающие сами найдут критерии «хорошо» и «плохо» и выберут исходя из них «свою Best Practice». Главное, чтобы было из чего выбирать и возможность выбора.
Самый простой из критериев: функционал \ стоимость.
При публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок — и это норма для нашего рынка, некоторые скандалы даже дошли о печати.
Дельта будет означать размер маржи подрядчика и откатов. Собственно, во многом из-за этого и не публикуют ни проекты, ни их стоимость. Это же «страшная тайна».
Если заказчик ткнул на аналог и сказал «хочу такую же», то это уже риск подрядчика, что две системы не совпадут.
Наоборот, подрядчик ничем не рискует: дали ТЗ — сделал по ТЗ. Это заказчику рискует тем, что полученное по его ТЗ его же не устроит.
Здесь еще будет играть фактор, что все стандартное и типовое будет на порядок дешевле и надежнее нетипового и уникального.
Ну да, будет дешевле. Но будет ли решать нужные задачи?
Когда опубликуют, то желающие сами найдут критерии «хорошо» и «плохо» и выберут исходя из них «свою Best Practice».
Тогда можно и не публиковать ничего. Люди, которые заказывают работу, уже так делают.
Самый простой из критериев: функционал \ стоимость.
Теперь давайте найдем способ объективно оценить функциональность.
При публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок
Нет, не выяснится, потому что вы не системы предлагаете публиковать.
ТЗ его же не устроит.
Мы же говорили, что в любом случае «обычное ТЗ» его «не устроит», потому что, это «филькина грамота», т.к. за «правильное ТЗ», стоимостью 30% работ по проекту — никто платить не готов.
Теперь давайте найдем способ объективно оценить функциональность.
Вы считаете, что два технических устройства или два программных изделия нельзя сравнивать (оценивать) по функциональности?
Железку с железкой, программу с программой?
Нет, не выяснится, потому что вы не системы предлагаете публиковать.
Я предлагаю
для ЕА – публиковать: корпоративную архитектуру (рабочую) + библиотеку эталонных архитектур (по типам предприятий);
для ВРМ – публиковать: рабочие бизнес-процессы (а также всё к ним привязанное, типа RACI, метрики и т.п.) + каталоги типовых процессов (APQC PCF и т.п.);
для SE публиковать: эскизный, технический и рабочий проект + исходное типовое решение (по видам изделий).
Знак «+» отделяет «рабочую часть» (реализацию) от «эталонной»,
т.е. «реальный проектный мир» от «эталонного проектного мира»,
примерно как у Канта: «мир вещей» и «мир идей».
А Ваша была какая версия?
Мы же говорили, что в любом случае «обычное ТЗ» его «не устроит»
Это вы говорили. Я с этим не соглашался.
И да, речь-то не об этом, а о том, чьи риски.
Вы считаете, что два технических устройства или два программных изделия нельзя сравнивать (оценивать) по функциональности?
Я считаю, что это сложно делать объективно в общем случае. Вот есть два фотоаппарата, в одном только матричный замер экспозиции, в другом — только точечный. Как должны соотноситься их цены?
И это мы еще не перешли к надежности.
Я предлагаю
И ничто из этого — не система. Между проектом и реализацией — пропасть.
И ничто из этого — не система. Между проектом и реализацией — пропасть.
Подскажите тогда, в чем Вы видите различие между «проектом», один из документов (обложка) которого показан на рисунке ниже, и «реализацией»?
В помощь: Книга Методы инженерного творчества, Шипинский
Что вообще по-Вашему возможно публиковать «в принципе»? Какие артефакты? Публиковать «реализацию»?
Подскажите тогда, в чем Вы видите различие между «проектом», один из документов (обложка) которого показан на рисунке ниже, и «реализацией»?
Я могу взять это "описание программы", пойти и запустить? Нет? Тогда оно для меня бесполезно.
Что вообще по-Вашему возможно публиковать «в принципе»? Какие артефакты?
Зависит от целей публикации, очевидно же.
Я могу взять это «описание программы», пойти и запустить? Нет? Тогда оно для меня бесполезно.
Такие понятия как «документация на программу» (точнее «программное изделие») Вы как себе представляете?
Указанная документация по-Вашему «бесполезна»? Для чего тогда подобную документацию изготавливают? Ей литеры присваивают?
Зависит от целей публикации, очевидно же.
Пытаюсь от Вас получить прямой ответ, и все никак.
Какие могут быть тогда вообще «цели публикации» и «что» под конкретную цель нужно публиковать?
Указанная документация по-Вашему «бесполезна»?
Она бесполезна для конечного заказчика в отрыве от программы.
Какие могут быть тогда вообще «цели публикации» и «что» под конкретную цель нужно публиковать?
А это вы предлагаете публиковать, а не я. И вы пишете "при публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок — и это норма для нашего рынка, некоторые скандалы даже дошли о печати". Если это ваша цель, то вам придется выкладывать (а) сами "изделия" и (б) методику и результаты их испытаний. Иначе ваша цель достигнута не будет.
Я-то просто публикую свои разработки в open-source, и мои цели это прекрасно решает.
Если это ваша цель, то вам придется выкладывать (а) сами «изделия» и (б) методику и результаты их испытаний. Иначе ваша цель достигнута не будет.
Более точно было бы так:
— изделие (система), результат SE, его вообще-то выложить сложно, т.к. в общем случае это «Большая система», включая территориальную сеть, объекты, средства автоматизации и может быть программы (причем не обязательно);
— документация на разработку (конструкторская, программная)
— документация на эксплуатацию (эксплуатационная)
— прочая документация (ПМИ, ТУ и т.п.). Есть еще направления «технологическая док.», «ремонтная док.» и т.д.
Это взгляд со стороны «отечественной SE».
Я-то просто публикую свои разработки в open-source, и мои цели это прекрасно решает.
Что конкретно Вы публикуете? И какие цели это решает?
(del, ошибся уровнем)
По своему опыту SE могу сказать, что оно всегда начинается в оборонных отраслях, затем полезный выхлоп переносится на технологии и бизнес-процессы, необходимые для реализации принятой большой или даже сверхбольшой системы и ее элементов (тут уже речь о BPM+EA), и, наконец (но не в нашей стране), желание подзаработать денег на супердостижениях в ходе реализации такого сложного и передового проекта, который был затеян, приводят к «Best Practice» & ххBOK, а они, в свою очередь, рождают новое поколение прикладных гаджетов, полезняшек и протчая и протчая, в итоге за ту же себестоимость появляется принципиально новый продукт, новое поколение «поющих утюгов» и прочей утвари.
Можете конкретизировать? «по своему опыту SE» какой-нибудь пример?
Возьмем отрасль, в которой мы впереди планеты всей в настоящее время. Системы ПВО/ПРО. Всеобъемлющие по своей структуре, природе элементов, протоколам информационного взаимодействия, всегда построенные на базе разумного компромисса между идеальным представлением заказчика и достижимым уровнем технологий. Для реализации оптимального SE-проекта всегда требуются доработки существующих технологий, поиски новых способов организации взаимодействия как внутри кооперации исполнителей, так и внутри каждого предприятия такой кооперации — ВРМ+ЕА во всей красе и полноте; затем обучить непосредственно персонал этих предприятий, а также персонал, эксплуатирующий систему с учетом и использованием достижений «Best Practice» & ххBOK в этой отрасли. Получаем на выходе конфетку типа С-Х00, плюс новейшие технологии изготовления ее элементов, как правило, поддерживающие масштабирование и тиражирование, плюс новый уровень бизнес-процессов как внутри предприятий-изготовителей, так и по их взаимодействию, плюс новый уровень руководства персоналом, обеспечивающий осознанное выполнение им своих задач. Детализировать далее невозможно. Беда наша в том, что никакого выхлопа в обычную экономику данные достижения не привносят. Хотя… Люди перетекают иногда, что в общем-то, определенную ценность тоже имеет
Возьмем отрасль, в которой мы впереди планеты всей в настоящее время. Системы ПВО/ПРО.
Вам об этом из зомбоящика рассказали?
Лучше ему не верить, обычно в чем «мы впереди планеты всей в настоящее время» там не говорят: коррупция, особенно в оборонке (самая закрытая и коррумпированная структура – это первая военная тайна).
Но даже если у нас еще и развивается ПРО (благодаря советскому заделу), то все равно это уже не так критично.
Разговоры «про ПРО» (нераспространение ЕвроПРО, надежда на наше ПРО – не важно) – это «газетные байки», политическая пропаганда, примерно то же самое, что я рассказываю по теме ЕА\ВРМ\SE: «управленческие уловки» (management fad), пропаганда, fake news – причем с обеих сторон (мы и США).
Нет защиты от МБР, ни у нас, ни у них, и – это вторая военная тайна.
Пара ссылок:
Межконтинентальная баллистическая ракета — абсолютное оружие. И это не преувеличение.
…созданные ещё в 1970–80-е годы средства до сих пор легко преодолевают ПРО.
… начинается создание сложных баллистических целей с сотнями и тысячами ложных элементов, и никаких противоракет для всего этого многообразия просто нет.
Детализировать далее невозможно.
Откуда такой вывод?
делением атомного ядра управлять научились, а вот какую-то «детализацию» выполнить не сможем?
плюс новый уровень бизнес-процессов как внутри предприятий-изготовителей, так и по их взаимодействию,
Операционная модель коррупционных схем? В какой нотации?
(шутка,… а может и нет, — для СКР может пригодиться)
плюс новый уровень руководства персоналом, обеспечивающий осознанное выполнение им своих задач.
Это про что? Про коммунизм? Про В. Губанова и П. Корчагина? Иначе, какое оно «осознанное» — работать, понимая что «результаты труда, так или иначе, присваиваются владельцами капитала»?
Беда наша в том, что никакого выхлопа в обычную экономику данные достижения не привносят.
А почему у них оборонка «привносит» в гражданку?
ТСР\IP, тот же IDEF и масса всего остального IT-шного и даже BPM-ного.
В чем сложности «у нас»?
Поясните, «не жалея букв». Хотелось бы Ваше «развернутое пояснение», учитывая, что «родина» SE – все же оборонка.
К сожалению, безапелляционность утверждений не оставляет мне пространства на развернутый ответ. Не смею детализировать, так как некоторая информация не теряет своей значимости в течение десятилетий. Смею лишь заметить, что реальность, а не фейковость возможностей ПВО/ПРО России подтверждается практически (читайте не геополитические обзоры, а просто информацию из Сирии, а также о результатах испытаний наших систем от С-Х00 до А-Х35). При том, что именно уровень системных проработок обеспечивает не только паритет, но и несомненное преимущество отечественных систем вооружений над уровнем наших «партнеров».
А насчет выхлопа в гражданку — ответ на поверхности. Почему у нас нет малого и среднего бизнеса? Потому же нет и выхлопа в гражданку.
А насчет выхлопа в гражданку — ответ на поверхности. Почему у нас нет малого и среднего бизнеса? Потому же нет и выхлопа в гражданку.
безапелляционность утверждений не оставляет ...
утверждений моих или конструктора Соломатина?
В любом случае, мы оба можем ошибаться.
А насчет выхлопа в гражданку — ответ на поверхности. Почему у нас нет малого и среднего бизнеса? Потому же нет и выхлопа в гражданку.
У нас нет МСБ? Мне казалось его давно «как грязи». «На поверхности» ничего не увидел.
Не теряю надежды на «Ваше развернутое пояснение, которое очень ценно, учитывая, что «родина» SE – все же оборонка».
Соломатина, к сожалению, не знаю в проблематике ПВО/ПРО. Знаю Соломонова (который с другой стороны баррикад :) ), Басистова, Бункина, Ефремова, много можно назвать фамилий. Только зачем? Вопрос ведь заключается в другом. Вопрос в том, что локомотив SE — оборонка. Оно так и есть, здесь мы не спорим. И уровень развития данной отрасли инженерного искусства (знания либо технологии — слишком узко будет сказано) в СССР, а затем России пока еще достаточно высок. Базируется это на универсальной подготовке по программам еще советской средней и высшей школы, учившим не только набору знаний, но и методам самостоятельного их применения и дальнейшего самообразования. Что касается МСБ — его вклад в ВВП России составляет менее 20%. В то же время для Китая это более 60%. И при этих наших жалких 20% не менее половины предприятий МСБ являются инструментами для обнала, к сожалению. Хорошо знаю это, имея опыт работы и в банковской сфере. А почему не перетекает выхлоп из оборонки? Вот недавно была иллюстрация, когда штрафовали предпринимателя на Дальнем Востоке, фермера, который одел на свою буренку приемопередатчик GPS. Незаконно, ёшкин кот! Какие уж тут условия для МСБ вообще и для перетока в него передовых технологий и прочих достижений из оборонки, в частности? Дорога тут предстоит большая и тернистая. Но идти надо!
Вопрос в том, что локомотив SE — оборонка. Оно так и есть, здесь мы не спорим. И уровень развития данной отрасли инженерного искусства (знания либо технологии — слишком узко будет сказано) в СССР, а затем России пока еще достаточно высок. Базируется это на универсальной подготовке по программам еще советской средней и высшей школы, учившим не только набору знаний, но и методам самостоятельного их применения и дальнейшего самообразования.
Хотелось бы поподробней. Я помогу вопросами:
Отечественные SE-ГОСТы, включая РВ 15.ххх устаревают, не развиваются. Что делать оборонке?
Использовать их «до последнего» или «садиться» на западные SE?
Переходить на SEBOK, BKCASE (МО США там участвует) и т.п.?
Ниже обсуждаем профстандарт «Инжнер-Системотехник», «Инженер по SE».
Что должно войти в него? Желательно дать предложения в той же ветке.
По rusEA что предложите? Внедряем DoDAF или отечественный фреймворк?
BPM как используете? Какие другие проблемы отечественного оборон-SE? Как их решать?
Операционная модель коррупционных схем? В какой нотации?
(шутка,… а может и нет, — для СКР может пригодиться)
Встречал попытку от одного украинского консультанта на уровне «рисовалки» с нестандартной нотацией.
Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку». Не может быть одного универсального ТЗ или «архитектуры» или еще чего в этом роде на все случаи жизни и для всех проектов. Для всех могут быть общие требования, которые потом в любом случае необходимо детализировать и творчески применять для каждого конкретного более или менее сложного проекта. Это только болты можно точить по единому стандарту, да и то разный металл для разных областей применения. Даже в бывшем СССР, на опыт которого Вы ссылаетесь, были ГОСТы — общие требования, и потом для каждого изделия уже конкретно своя документация и свои требования.
Как Вы себе представляете единый документ на все строения, которые будут построены — от частного дома до здания завода? Я могу представить только так: для всех — общие требования, для каждого свой проект в зависимости от климатической зоны, вида грунтов и сейсмоактивности. Да, могут быть и типовые проекты для постройки одинаковых строений, но только в одном и том же регионе.
Если сделали, к примеру, систему для сети аптек в городе N, то ее можно тиражировать и в других городах. Но для автодиллеров это придется переделывать под их специфику. Да, не полностью переделывать, что-то можно использовать и оставить как есть, но не полностью 100% это будет применимо.
Нужна золотая середина — чтобы не тратить лишние ресурсы, да, общее что можно — это нужно вынести в общие требования. А для каждого случая уже смотреть и работать на месте и прорабатывать конкретные детали.
Как Вы себе представляете единый документ на все строения, которые будут построены — от частного дома до здания завода? Я могу представить только так: для всех — общие требования, для каждого свой проект в зависимости от климатической зоны, вида грунтов и сейсмоактивности. Да, могут быть и типовые проекты для постройки одинаковых строений, но только в одном и том же регионе.
Если сделали, к примеру, систему для сети аптек в городе N, то ее можно тиражировать и в других городах. Но для автодиллеров это придется переделывать под их специфику. Да, не полностью переделывать, что-то можно использовать и оставить как есть, но не полностью 100% это будет применимо.
Нужна золотая середина — чтобы не тратить лишние ресурсы, да, общее что можно — это нужно вынести в общие требования. А для каждого случая уже смотреть и работать на месте и прорабатывать конкретные детали.
Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку».
Смотря, что под ними понимать.
Под «серебряной пулей» я понимаю НОТ и подобные научные подходы (СОВНОТ во главе с Куйбышевым был образован еще в 1923).
Про научный подход, унификация, стандартизация, Global BPM, развитие «Open Source» до «Открытый процесс» и т.п. обсуждали в
Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
Эволюционируя от «Кадры решают всё» к «Процессы решают всё» советская научная мысль пришла бы к этому и сегодняшние павильоны ВДНХ трансформировались бы в выставку Хороших Процессов народного хозяйства (e-выставка ХПНХ). А принцип «Open Process» был бы принудительно инкорпорирован во все отрасли народного хозяйства
Не только само производство товаров и услуг, но и инженерия и даже наука может быть организована в виде «промышленного конвейера» (почти по Г. Форду). По открытиям и изобретениям:
• Мы не столько изобретаем решения, сколько открываем их. Соболезнования творческим натурам: это всего лишь обрабатывающий информацию голем, начищающий свое собственное эго и озабоченный поднятием кармы.
• Интеллект — это социальный эффект, хотя он и ощущается как что-то личное. Человек, отрезанный от других, перестает думать. Мы не можем ни определить проблемы, ни оценить их решения без других людей.
и как реализация этого:
должен быть всего лишь налажен «промышленный конвейер изобретений», нечто подобное «Системной Инженерии», — как технология «Научной инженерии».
Т.е. свод знаний «по проектированию \ производству открытий и инноваций».
Подробнее здесь «Социальная архитектура»
Я полагаю, что, не смотря на наличие «гениальности», — как важного фактора развитие науки, эволюция науки в целом — идет вне зависимости он него.…
Лучший пример подобного конвейера, организованного Сталиным и Берия, – это Советский атомный проект.
«Волшебные таблетки» это:
Это подходы к типовому проектированию — как методологии «Best Practice» типа SE (но очищенного от болтовни, маркетинга и пиара),
это реальные и практические «Best Practice» (не псевдо, как сегодня), публикуемые типовые проекты, «полнометражные» примеры, архитектуры, референтные (эталонные) модели, отраслевые подробные классификаторы бизнес-процессов, ЧаВо по их развертыванию (внедрению), регламенты (графические, табличные, текстовые) и т.п.
Главное создать среду (инфраструктуру) для обмена опытом путем публикации успешных и неуспешных (это тоже очень важно) реализаций, их артефактов. А эти реализации сами покажут, какие практики «Лучшие», а какие не очень.
Вы думаете, что проекты разных системных интеграторов сильно отличаются друг от друга?
Да – отличаются.
Одни изобретая один и тот же «велосипед», наступили «вслепую» на 50 «граблей», другие при таком же «велосипеде» также «вслепую» на 150 граблей.
А если бы им все эти грабли заранее «подсветили» (типовые проекты, эталонные модели и т.п.), то не только легче было бы пройти «инженерной тропкой», но и «изобретать велосипед» вообще не пришлось бы – а лишь его заимствовать (типовое проектное решение).
Это как раз позволит: «чтобы не тратить лишние ресурсы»
Если мысль не донес, — скажите, я по Вашему тексту отвечу что-нибудь на примерах.
Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку».
Скорее здравый опенсорс по связи теории и практики.
Как Вы себе представляете единый документ на все строения, которые будут построены — от частного дома до здания завода?
Технический регламент по общим требованиям вполне возможен.
Если сделали, к примеру, систему для сети аптек в городе N, то ее можно тиражировать и в других городах. Но для автодиллеров это придется переделывать под их специфику.
Самое забавное в том, что в обеих случаях главный бизнес-процесс абсолютно одинаков — Оказание услуг (торговли).
Нужна золотая середина — чтобы не тратить лишние ресурсы, да, общее что можно — это нужно вынести в общие требования. А для каждого случая уже смотреть и работать на месте и прорабатывать конкретные детали.
Помнится меня когда-то учили тому, что решением задачи является сумма общего рещения и решения при заданных начальных условиях.
Могу сказать, что в принципе считаю себя Системотехником, так как контролировал разработку достаточно сложной и ответственной системы управления в энергетической сфере.
По дисциплинам — да это требует знаний и опыта в достаточно разных сферах — механики, электроники, софта, измерений, стандартизации, тестирования и еще кучи других, так как даже простые решения о том, реализовать ту или иную функциональность в программе, железе, ПЛИС или микроконтроллере с учетом всех факторов, включая ресурсы и наличие/наем нужных разработчиков, даются не так легко.
Большим подспорьем в конкретном случае с АСУ является моделирование — потому что дает возможность хоть на раннем этапе оценить требования к системе и прикинуть, как может быть решена основная задача. Но к сожалению тут универсальных средств нет и промоделировать систему управления предприятием на той же системе уже невозможно.
Могу сказать, что в принципе считаю себя Системотехником
Тогда как по-Вашему, что должно войти в профстандарт «Инжнер-Системотехник», «Инженер по SE»?
Насколько понимаю, такого ПрофСтандарта пока нет, но есть, например,
Специалист в области проектирования автоматизированных систем управления технологическими процессами
Самое забавное в такой профессии это то, что по некоторым исследованиям только 15% людей обладают системным мышлением.
Из того, что мне пригодилось и в принципе самое главное:
- Умение гуглить и находить информацию в сети Интернет в том числе общение на тематических форумах
- Основы электроники и схемотехники
- Основы программирование микроконтроллеров
- Основы и устройство DSP, цифровой обработки сигналов, цифровых фильтров
- Основы ПЛИС
- Языки программирования Си, Java(сегодня может быть Питон)
- Cтандартизация и сертификация
- Основы проведения экспериментов, измерений и анализ их результатов
- Метрология
- Английский язык
- Моделирование — Matlab/Simulink, Pspice
- Основы 3D проектирования и моделирования — Solidworks, Comsol Multiphisics.
- Менеджмент требований
- Основы систем контроля версий, баг-трекеров.
- Теория автоматического управления
- IoT
- Локальные Сети (CAN, RS482, Modbus, Ethernet и т.д.)
- Оформление схем и документации по Госту — Спецификаций, Паспортов, Инструкций и т.д.
По практике — как минимум 2-3 + дипломник реальных проекта на микроконтроллерах/ПЛИС c использованием отладочных плат от начала и до конца с документацией.
Это из того, что вспомнил специфического.
Это не системщик в понимании темы.
А кто?
ПС. Забыл еще основы теории надежности
Инженер по АСУ.
Для системщика по теме обсуждения нужны менеджмент, маркетинг, логистика, кибернетика, теория систем и много еще разной зауми, включая основы бухучета.
Не говоря уже о базовых матстатистике и теории вероятности. ПЛИС и многое прочее в реальности всего лишь практическое приложение к алгебре логики и прочему подобному.
Для системщика по теме обсуждения нужны менеджмент, маркетинг, логистика, кибернетика, теория систем и много еще разной зауми, включая основы бухучета.
Не говоря уже о базовых матстатистике и теории вероятности. ПЛИС и многое прочее в реальности всего лишь практическое приложение к алгебре логики и прочему подобному.
Для системщика по теме обсуждения нужны менеджмент, маркетинг,
Я тут ругаю маркетинг и менеджмент (точнее их уловки): «управленческие уловки» (management fad), пропаганду, манипуляцию терминами и т.п.
а Вы их системщикам …
Зачем маркетинг — то системщику? Продать свой проект?
Я еще про психологию забыл! :))
Что изучает маркетинг? — Внешнюю среду. Внешняя среда тоже система. От SWOT анализа Вы отказываетесь? От стратегического планирования тоже? И многих прочих критических элементах систем тоже?
Что есть менеджмент без пены? Это наука об управлении человеческими организациями. Как без него строить социотехническую систему?
Что изучает маркетинг? — Внешнюю среду. Внешняя среда тоже система. От SWOT анализа Вы отказываетесь? От стратегического планирования тоже? И многих прочих критических элементах систем тоже?
Что есть менеджмент без пены? Это наука об управлении человеческими организациями. Как без него строить социотехническую систему?
Но без тех дисциплин, что я привел, системщик тоже будет неспособен разбить задачу на блоки и решить ее наиболее технически оптимальным способом. Не зная, что умеют ПЛИС, например, вы не сможете их правильно применить.
Насчет ваших согласен. Из нетехнических специальностей мне пригодилось:
- основы логистики
- основы бухучета,
- определение себестоимости продукта/системы — калькуляции ROI/RORE
- основы ведения НИР, НИОКР, основные этапы разработки и исследований
- маркетинг, это в принципе для системщика управление требованиями — нет смысла туда углубляться глубже.
Начнем сначала. Рассмотрим человека. Любой человек — система. Внутри него можно выделить еще ряд систем: пищеварения, дыхания, кровообращения и далее по списку. Вместе с тем человек входи в системы семья, работа, государство и далее по списку.
С моей точки зрения Вы считаете системщиком специалиста по системе автоматизации организации. Но для меня это только одна из подсистем организации. Вспомнилась одна работа. Нужно было автоматизировать один процесс. Чтобы я не отвлекался на мелочи, мне в помощь дали программиста. Мы сделали эскиз и показали его заказчику. Ему очень понравилось и он начал плотно контролировать ход работы. Через некоторое время он потребовал убрать меня из проекта потому что программист сидел целыми днями, а я забегал к нему на пару минут, смотрел и говорил что доделать, а что переделать. Мол мне не за что платить. Я ушел из проекта и он рассыпался. Сам программист сказал что его можно заменить на любого, а меня заменить в этом проекте некем, потому что я детально знаю не только сам процесс, но и потребности с возможностями всего его окружения. С точки зрения многих участников этого форума заказчик скорее всего был прав, ведь за что платить мне больше программиста если я не написал ни строчки кода, только мешал работать. А с моей точки зрения я работал системщиком, которым может работать не каждый программист. :))
С моей точки зрения Вы считаете системщиком специалиста по системе автоматизации организации. Но для меня это только одна из подсистем организации. Вспомнилась одна работа. Нужно было автоматизировать один процесс. Чтобы я не отвлекался на мелочи, мне в помощь дали программиста. Мы сделали эскиз и показали его заказчику. Ему очень понравилось и он начал плотно контролировать ход работы. Через некоторое время он потребовал убрать меня из проекта потому что программист сидел целыми днями, а я забегал к нему на пару минут, смотрел и говорил что доделать, а что переделать. Мол мне не за что платить. Я ушел из проекта и он рассыпался. Сам программист сказал что его можно заменить на любого, а меня заменить в этом проекте некем, потому что я детально знаю не только сам процесс, но и потребности с возможностями всего его окружения. С точки зрения многих участников этого форума заказчик скорее всего был прав, ведь за что платить мне больше программиста если я не написал ни строчки кода, только мешал работать. А с моей точки зрения я работал системщиком, которым может работать не каждый программист. :))
Не зная, что умеют ПЛИС, например, вы не сможете их правильно применить.
Помнится в одном старом американском учебнике по программированию была глава типа «А всегда ли нужно программировать микроконтроллер?»
Идея проста. Одно и тоже устройство можно реализовать в жестком железе (начиная с логических микросхем малой или большой интеграции, одной из которых является ПЛИС) или на универсальный блок запрограммировать специальный софт. Далее никакой техники, одна экономика, демонстрирующая случаи, когда можно все сделать на ПЛИС, а когда лучше микроконтроллер с программой. Оплата программиста в нем считалась значительно больше стоимости железа. :))
Я вам больше скажу. Одну и ту же систему можно сделать на ПЛИС или DSP, микроконтроллерах ARM или процессорах Intel, материнках в формате ATX, ноутбуке или стойках cPCI,VPX, с использованием интерфейсов Ethernet или CAN или RS485 или своего доморощенного протокола, с использованием PCIexpress или без. И в итоге получить решение, которое функционально делает то же самое, но будет иметь абсолютно разные затраты на разработку и ее длительность, стоимость железа, возможность серийного производства, имеет разные требования к экспертизе разработчиков и еще множество отличий.
Чистая экономика, конечно...
А «бухучет» — то зачем инженеру?
Управленческий и налоговый учет тоже нужен?
Управленческий и налоговый учет тоже нужен?
Мы говорим об инженерах или о специалистах по системе всего предприятия? Система управления без учета неработоспособна. Управлять можно только тем, что можно измерить. В том числе инструментами бухгалтерского и управленческого учета.
Мы говорим об инженерах или о специалистах по системе всего предприятия?
Ветка называется:
что должно войти в профстандарт «Инжнер-Системотехник», «Инженер по SE»?
Инженер — это точно не бизнесмен и бизнес-навыки «для профессии» вряд ли нужны. Знание предметной области (отрасли) нужно, но при этом достаточно что «бухучет есть» и очень примерно «что это такое».
Если мы говорим об ЕА, то разработчик и администратор ЕА (архитектор) должен находиться в треугольнике «бизнес» — «технология» — «инфраструктура, включая ИТ» — точнее в середине этого треугольника, такой «корпоративный архитектор» (не системный архитектор) должен знать по «соответствующей» выжимке с каждой стороны треугольника.
У системного архитектора уже свой, и другой «треугольник», и его навыки уже будут ближе к инженеру SE.
Поэтому «системотехник» (SE) и «корпоративный архитектор» — это во многом разные направления.
Об этом говорил здесь
«Хочешь быть системным архитектором? Там только свет и чистота…»
Хорошо бы конечно ролевую структуру всех этих SE\ВРМ\ЕА нарисовать.
Есть проект профстандарта на специалиста ВРМ.
Извините, но даже генеральный директор, его замы и другие специалисты, не имеющие акции предприятия, бизнесменами не являются. Вы для начала определитесь на каком уровне работают «системотехник» (SE) и «корпоративный архитектор». Если это рядовые специалисты-инженеры, то я тогда вообще ничего не понимаю. По моему скромному мнению вопросы архитектуры и прочие системные вопросы предприятия это вопросы исключительно топменеджмента, имеющего соответственную подготовку и возможности.
Ну и разумеется разного калибра консалтеров. :))
Ну и разумеется разного калибра консалтеров. :))
Вы для начала определитесь на каком уровне работают «системотехник» (SE) и «корпоративный архитектор». Если это рядовые специалисты-инженеры, то я тогда вообще ничего не понимаю
Ха-рооо-ший вопрос. Уверен, что «корпоративные архитекторы» — не топы, но вот целевые потребители описания ЕА — топы.
«Классический» Системотехник — это вообще почти всегда внешний подрядчик, т.к. его задача «изо дня в день» разрабатывать что-то новое, сложное и большое.
Они обычно «живут» в проектных организациях, хотя некоторые «операционные» (классические) компании могут и их себе позволить.
Это проектная работа, фактически по проектированию предприятия и его «крупных» частей. Жизнь предприятия в условиях постоянных крупномасштабных" изменений — видимо не стоит считать «нормой».
А я наоборот абсолютно уверен в том, что корпоративный архитектор это топ. В ряде компаний он называется «Директор по развитию». Кого он возьмет к себе в помощники это его проблема, имеет право советоваться хоть с уборщицей. А целевой потребитель — вся организация. Кто персонально определяет устав предприятия. Это может быть учредитель, совет директоров и т.д. Вопрос ведь не в описаниях, а в их реализациях. По простейшей архитектурной модели — штатному расписанию принимают на работу и устанавливают зарплату.
А я наоборот абсолютно уверен в том, что корпоративный архитектор это топ. В ряде компаний он называется «Директор по развитию».
Уверен, что «Директор по развитию» и слов то таких не знает: The Enterprise Architecture Body of Knowledge (EABOK), Захман, ТОГАФ и т.п.
Вы под ЕА понимаете то, что в этих книжках сказано?
«Директор по развитию» даже в бизнес-архитекторы записывать не нужно.
Попробуйте составьте framework своего домохозяйства, как я предлагал здесь:
3 Конкурс на описание «household architecture»
А Вы подобное хотите на топов «повесить»?
А целевой потребитель — вся организация.
Зачем описание ЕА уборщице и бухгалтеру?
Уверен, что «Директор по развитию» и слов то таких не знает: The Enterprise Architecture Body of Knowledge (EABOK), Захман, ТОГАФ и т.п.
Слов не знает, но ведь делает именно то, что в них написано! Когда-то в Росссии и слова бизнес не знали.
Зачем описание ЕА уборщице и бухгалтеру?
Ну если для Вас организация это уборщица и бухгалтер, то я тогда пас.
Слов не знает, но ведь делает именно то, что в них написано!
Можно конкретику в терминах ТОГАФ или еще кого из ЕА, про деятельность «Директор по развитию» в роли корпоративного архитектора?
Лениво переводить на «птичий язык».
Читайте первое что нашел Великий Гугль и возможно увидите то, что роль архитектора предприятия написана несколькими фразами: www.rabota.ru/articles/hr/dolzhnostnaja_instruktsija_direktora_po_razvitiju_dolzhnostnye_objazannosti_direktora_po_razvitiju_obrazets_dolzhnostnoj_instruktsii_direktora_po_razvitiju-3999
Читайте первое что нашел Великий Гугль и возможно увидите то, что роль архитектора предприятия написана несколькими фразами: www.rabota.ru/articles/hr/dolzhnostnaja_instruktsija_direktora_po_razvitiju_dolzhnostnye_objazannosti_direktora_po_razvitiju_obrazets_dolzhnostnoj_instruktsii_direktora_po_razvitiju-3999
Все равно, не понимаю.
По Вашей ссылке приведена Должностная инструкция директора по развитию, должностные обязанности директора по развитию
Описание ЕА может разрабатываться вообще без цели «развитие», просто для того чтобы зафиксировать «as is»:
обычно «бардак в as is», но без надежды его упорядочить.
По Вашей ссылке приведена Должностная инструкция директора по развитию, должностные обязанности директора по развитию
Описание ЕА может разрабатываться вообще без цели «развитие», просто для того чтобы зафиксировать «as is»:
обычно «бардак в as is», но без надежды его упорядочить.
Для Вас важнее описание чем работа? «Вам шашечки или ехать?» Описание того что есть в новой нотации ценности не имеет.
Я все равно не понял: когда делаем описание ЕА — только «as is» и вне любого развития, то при чем здесь директор по развитию «вообще», и тем более в роли корпоративного архитектора?
Ответьте на простой вопрос: Зачем нужно это описание и именно в такой нотации?
Чувствую скоро Вы скажете о том, что архитекторы (градостроительные) нужны только для того, чтобы работать экскурсоводами.
Зачем новое проектировать? Нам лучше описать то что есть.
Чувствую скоро Вы скажете о том, что архитекторы (градостроительные) нужны только для того, чтобы работать экскурсоводами.
Зачем новое проектировать? Нам лучше описать то что есть.
Зачем нужно вообще ЕА — это другой вопрос (не менее спорный).
Мы же обсуждаем другое: Зачем в общепринятом подходе к ЕА (EABOK + куча фреймворков) нужен в качестве архитектора Директор по развитию, тем при описании ЕА типа «как есть»?
Мы же обсуждаем другое: Зачем в общепринятом подходе к ЕА (EABOK + куча фреймворков) нужен в качестве архитектора Директор по развитию, тем при описании ЕА типа «как есть»?
В карты я с Вами играть не сяду. Передергиваете знатно!
Что нужно? Организовать новое предприятие или улучшить работу старого. Для этого можно применить различные инструменты и их сочетания. Само по себе применение этих инструментов никому не нужно за исключением консалтеров, которые на этом живут.
Повторяю, вне разницы какие инструменты применяются, главным архитектором предприятия является его Генеральный директор, который делегирует некоторые полномочия своим замам и другим руководителям. В качестве начальника штаба по архитектуре предприятия ближе всего роль директора по развитию. Но во многих предприятиях равноважны главный инженер и главный технолог. А специалист-системщик знающий новомодные нотации максимум, как говорил мой начальник, — «ученый еврей при генерале», то есть буквально штатный консультант, не имеющий права принимать самостоятельное решение.
Что нужно? Организовать новое предприятие или улучшить работу старого. Для этого можно применить различные инструменты и их сочетания. Само по себе применение этих инструментов никому не нужно за исключением консалтеров, которые на этом живут.
Повторяю, вне разницы какие инструменты применяются, главным архитектором предприятия является его Генеральный директор, который делегирует некоторые полномочия своим замам и другим руководителям. В качестве начальника штаба по архитектуре предприятия ближе всего роль директора по развитию. Но во многих предприятиях равноважны главный инженер и главный технолог. А специалист-системщик знающий новомодные нотации максимум, как говорил мой начальник, — «ученый еврей при генерале», то есть буквально штатный консультант, не имеющий права принимать самостоятельное решение.
Ответьте на простой вопрос: Зачем нужно это описание и именно в такой нотации?
Вы про какую нотацию? Часто в ЕА не накладывается ограничений: рисуй в любой нотации.
В принципе основы бухучета требуются для того, чтобы корректно понимать себестоимость разработанного продукта и как он будет генерировать прибыль. Также чтобы понимать, что зарплату надо платить всем и вовремя, даже если работа есть только для одного — это поможет при планировании цикла разработки.
Да, верно: BPM-алхимики «плодовиты», у них мантр много, не меньше, чем у ЕА-алхимиков и SE. Напомню свои рассказы:
Бизнес-процессы: Как все запущено и запутано. Глава Первая
Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
по EA:
Enterprise Architecture vs алхимия предприятия. Ключевые мифы
Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие
Первый «писк» моды «Adaptive Case Management» пришелся на 2010-11. Тогда он не позиционировался как «убийца BPM» и иногда назывался даже как: adaptive BPM, dynamic BPM, agile BPM и т.п.
Это чтобы «плавно влиться» в рынок в составе раскрученного бренда «BPM».
Потом пришло время «противопоставления»: не покупайте их «старый» BPM, берите наш «свежий» ACM!
О подобном сценарии с BPM\BPMS – рассказывал в указанных статьях.
Когда-то на «птичьем рынке» был классический прием (такой же management fad как в IT) по продаже щенков (BPM\BPMS\ACM etc):
В коробке (Suite) продавца лежат несколько щенков – братьев от среднерослой дворняжки.
Потенциальный покупатель: Какой милый у Вас щенок справа! Породистый? А большим или маленьким он вырастет?
Находчивый продавец: Конечно породистый! Вы что сами не видите? А Вы любите больших или маленьких собак?
— Очень люблю маленьких!
— Как раз – то, что Вам нужно! Он только чуть-чуть подрастет и все!
— Как здорово! Как мне повезло, спасибо, покупаю, сдачи не нужно!
Следующий покупатель:
— Какой милый щенок! Породистый? А большим или маленьким он вырастет?
— А Вы любите больших или маленьких собак?
— Люблю больших собак!
— Как раз – то, что Вам нужно! Он, конечно же, вырастет огромным псом!
— Как здорово! Как мне повезло, спасибо, покупаю, сдачи не нужно!
Пойми своего клиента!
Продавцы на «ИТ-рынке» также Вас спрашивают: «Вам что больше нравится: BPM или ACM»? И независимо от Вашего ответа Вашей покупкой окажется один и тот же «Management-щенок» (может с переклеенной этикеткой).
Однако «высшим пилотажем» сейчас считается подход, когда их уже не противопоставляют друг другу, а говорят так:
«и то и то — круто, поэтому у нас они оба – и в одном флаконе»!
За примером ходить далеко не нужно:
Или другими словами:
Покупайте в свой горем:
ACM плюс BPM!
Они — решенье всех проблем:
И с ERP, и с CRM,
А может и с BSDM.
Бизнес-процессы: Как все запущено и запутано. Глава Первая
Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
по EA:
Enterprise Architecture vs алхимия предприятия. Ключевые мифы
Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие
Первый «писк» моды «Adaptive Case Management» пришелся на 2010-11. Тогда он не позиционировался как «убийца BPM» и иногда назывался даже как: adaptive BPM, dynamic BPM, agile BPM и т.п.
Это чтобы «плавно влиться» в рынок в составе раскрученного бренда «BPM».
Потом пришло время «противопоставления»: не покупайте их «старый» BPM, берите наш «свежий» ACM!
О подобном сценарии с BPM\BPMS – рассказывал в указанных статьях.
Когда-то на «птичьем рынке» был классический прием (такой же management fad как в IT) по продаже щенков (BPM\BPMS\ACM etc):
В коробке (Suite) продавца лежат несколько щенков – братьев от среднерослой дворняжки.
Потенциальный покупатель: Какой милый у Вас щенок справа! Породистый? А большим или маленьким он вырастет?
Находчивый продавец: Конечно породистый! Вы что сами не видите? А Вы любите больших или маленьких собак?
— Очень люблю маленьких!
— Как раз – то, что Вам нужно! Он только чуть-чуть подрастет и все!
— Как здорово! Как мне повезло, спасибо, покупаю, сдачи не нужно!
Следующий покупатель:
— Какой милый щенок! Породистый? А большим или маленьким он вырастет?
— А Вы любите больших или маленьких собак?
— Люблю больших собак!
— Как раз – то, что Вам нужно! Он, конечно же, вырастет огромным псом!
— Как здорово! Как мне повезло, спасибо, покупаю, сдачи не нужно!
Пойми своего клиента!
Продавцы на «ИТ-рынке» также Вас спрашивают: «Вам что больше нравится: BPM или ACM»? И независимо от Вашего ответа Вашей покупкой окажется один и тот же «Management-щенок» (может с переклеенной этикеткой).
Однако «высшим пилотажем» сейчас считается подход, когда их уже не противопоставляют друг другу, а говорят так:
«и то и то — круто, поэтому у нас они оба – и в одном флаконе»!
За примером ходить далеко не нужно:
Адаптивный кейс-менеджмент сочетает в себе гибкость, социальную составляющую и возможность накопления опыта — то, чего не хватает традиционному BPM. Но на практике в одной организации могут быть и такие процессы, которые требуют строгой регламентации, и те, которые должны оставаться гибкими.
Если для первых лучше использовать классический BPM-подход, то для вторых необходимо применять «Agile BPM» — то есть, АСМ.
В продукте «ххххх» мы объединяем ACM и BPM-подходы, что позволяет перейти на новый уровень и значительно повысить эффективность в управлении процессами.
Или другими словами:
Покупайте в свой горем:
ACM плюс BPM!
Они — решенье всех проблем:
И с ERP, и с CRM,
А может и с BSDM.
Во-первых, ACM это не BPM. Основа ACM — это обработка событий и ориентированность на Case (можно интерпретировать как «Дело»). Основа BPM — это в большей степени процессный подход.
Во-вторых, использование анекдотов и рекламных выдержек не добавляет Вам никаких аргумент. Это может сработать только на людях до определенного возраста.
Во-вторых, использование анекдотов и рекламных выдержек не добавляет Вам никаких аргумент. Это может сработать только на людях до определенного возраста.
Во-вторых, использование анекдотов и рекламных выдержек не добавляет Вам никаких аргумент. Это может сработать только на людях до определенного возраста.
Консалтерами все так сознательно запутано, что без упрощения — не разобраться с их «маркетинговой лапшой». А юмору «все возрасты покорны», поэтому не понял упрек на возраст.
А что, на ком-то «шапка горит»?
Пропущенные через «призму» юмора ультрамодные «аргументы консалтеров» позволяют лучше понимать: маркетинговый конвейер спекуляций, «управленческие уловки» (management fad), пропаганду, fake news.
Бытовые аналогии понятным языком показывают «классические приемы» и техники продвижения универсальных волшебных «таблеток» с высокой стоимостью, но сомнительным составом.
Очень многое, что пишут на эту тему и предлагают алхимики — не имеет никакого отношения ни к науке, ни к реальности (но ими позиционируется так).
Основная причина популярности алхимии — это просто закрытие информации, «не публикация» реализаций, нет открытого обсуждения — как деталей самих проектов BPM\ЕА\SE, так и реального их «выхлопа» (восторженные речи на конференциях — не в счет).
Есть позитивные движения, например, общенациональный конкурс «BPM-проект года», но хотелось бы развитие: больше деталей (проекты публиковать целиком) и шире охват (массовость).
По решению задачи отделить «мух от котлет», а область «computer science & engineering» от «alchemy & voodoo» — делаются только первые робкие шаги. Пока алхимия одерживает одну за другой победы над здравым смыслом.
На «Во-первых,» — напишу ответ отдельно.
Ответ на habrahabr.ru/post/346610/#comment_10620262
Удивляюсь, вначале красиво подрожали моей иронии:
и даже создали прикольную картинку с АСМ: правда там слово ВРМ не нужно было затирать, — было бы «комплексней».
Я уж обрадовался, понадеялся, что еще борец с алхимией появился.
Потом, Ваша ирония «растворилась», видимо, из-за того, что иронизировать над ЕА, ВРМ и SE можно, но вот покушаться на «святыню»: АСМ – это «кощунство»! Верно?
«это не BPM» – уже Очень Смешно.
Потому что: «что такое BPM» – никому не известно, смотрим указанную ранее статью «Как все запущено и запутано. Глава Первая»
Неоднократно был свидетелем, когда на крупной конференции или семинаре по «управлению бизнес-процессами» (BPM, Business Process Management – так, на всякий случай), — часами обсуждают ВРМ и подробно рассказывают о ВРМ-проектах. Все чинно, с умным видом.
Затем когда всем становится очевидно, что беседа идет на разных языках и совсем «о разных BPM» начинаются вопросы к докладчикам: так Ваша система – это же не ВРМ!
Затем достопочтенная публика задается вопросом: Что такое BPM? Час приводят «книжные» термины (цитаты из BPM CBOK, других «процессных библий») – подходящие на все случаи жизни, которые еще более образуют «BPM — кашу».
Вы о каком BPM?
«Как все запущено и запутано. Глава Первая»:
Вы про этот CASE?
Там же, первой главе:
Теперь к Вашему «священному АСМ»
По Вашей ссылке:
И это в консервативной wiki! Только это уже говорит, что до практического инженерного понимания этой технологии (или алхимии) предстоит еще долгий путь.
Хорошо. Давайте на паре примеров поймем, что такое АСМ.
Маркетинг и рекламу читать не будем, определений тоже не нужно (алхимия же), только на простых примерах («на пальцах»).
Пример первый, система документооборота.
Я хочу согласовать договор. Есть стандартный конвейер согласования: Отдел 1, Отдел 2, Отдел 3 и т.д.
Все это прошито в Workflow. Я захожу в систему DocFlow, ввожу договор, атрибуты, вызываю преднастроенный шаблон Workflow (с заданными маршрутами) и жму «поехали». Каждому согласанту в соответствии с логикой шаблона даются поручения, выскакивают окошки, требуют заполнения нужных полей и т.п. Потом, когда все отжали нужные кнопки, мне прилетает «Готово». Это в Вашем понимании ВРМ?
Но вдруг в одном экземпляре процесса (согласования договора N) или «кейса» (как правильно?) что-то пошло не так, и договор отклонили, мне прилетает соответствующее сообщение с комментарием. Я читаю, сильно думаю и решаю, что это «нестандартная» ситуация и нужно отправить договор «Иванову», который вообще не участвует в штатном Workflow.
Я жму кнопку: выбрать Иванова и отправить ему договор, а после получения правок от Иванова далее продолжается алгоритм «штатного конвейера».
Это добавка уже реализует подход АСМ? Конечно, ведется архив кейсов, и любой «на моем месте» может вызвать базу знаний и посмотреть как в подобном случае (нештатной ситуации) кто-либо действовал.
Иной Вариант первого примера, когда у меня вообще нет преднастроенного шаблона (т.е. «неструктурированный процесс») и я вручную в DocFlow создаю последовательность поручений (по произвольному списку), прикрепляя файл договора, – это тоже АСМ?
Второй пример покажите на процессе «Управления инцидентами», как он работает в режиме ВРМ и как в режиме АСМ?
Иногда употребляют «Adaptive Workflow Management System» (Pega, Papyrus и др.) — это тоже АСМ? В чем отличие?
Удивляюсь, вначале красиво подрожали моей иронии:
bipiem не оставил выбора, придется применить магическое заклинание и открыть портал ACM
и даже создали прикольную картинку с АСМ: правда там слово ВРМ не нужно было затирать, — было бы «комплексней».
Я уж обрадовался, понадеялся, что еще борец с алхимией появился.
Потом, Ваша ирония «растворилась», видимо, из-за того, что иронизировать над ЕА, ВРМ и SE можно, но вот покушаться на «святыню»: АСМ – это «кощунство»! Верно?
Во-первых, ACM это не BPM. Основа ACM — это обработка событий и ориентированность на Case (можно интерпретировать как «Дело»). Основа BPM — это в большей степени процессный подход
«это не BPM» – уже Очень Смешно.
Потому что: «что такое BPM» – никому не известно, смотрим указанную ранее статью «Как все запущено и запутано. Глава Первая»
Неоднократно был свидетелем, когда на крупной конференции или семинаре по «управлению бизнес-процессами» (BPM, Business Process Management – так, на всякий случай), — часами обсуждают ВРМ и подробно рассказывают о ВРМ-проектах. Все чинно, с умным видом.
Затем когда всем становится очевидно, что беседа идет на разных языках и совсем «о разных BPM» начинаются вопросы к докладчикам: так Ваша система – это же не ВРМ!
Затем достопочтенная публика задается вопросом: Что такое BPM? Час приводят «книжные» термины (цитаты из BPM CBOK, других «процессных библий») – подходящие на все случаи жизни, которые еще более образуют «BPM — кашу».
Вы о каком BPM?
«Как все запущено и запутано. Глава Первая»:
… Для успешных продаж «взбрасываются» новые термины и подменяются прежние названия, выдумываются модные фишки, проводится ре-брендинг, вводится тавтология и путаница (см. выше «управление управлением»), а потом создается ореол «успешности» и необходимости внедрений т.п.
Главное: воду сделать мутной, а остальное — «дело техники».
В далеком 2000-ом, в основном употреблялся единственный термин: CASE. И его было достаточно. Когда при проектировании «системы» формализовывали бизнес-логику и укрупненные алгоритмы взаимодействия исполнителей (систем), то в слове CASE понимали S=System и использовали соответствующие инструменты, например, ARIS\EPC.
Когда формализовывали детальные алгоритмы при проектировании ПО, то понимали S=Software и использовали, например, RUP\UML. Уже тогда Rational позволял генерировать код из моделей UML. При этом обходились без разных «BPM\BPMS» и «BPM-like» направлений.
Напомню, что CASE-технология — это инструментарий для системных аналитиков, проектировщиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования систем и разработки ПО. Проблема в том, что этот термин был монетизирован, поэтому нужен «свежий», на котором «еще можно заработать».
Вы про этот CASE?
Основа BPM — это в большей степени процессный подход.
Там же, первой главе:
1.4 Процессное управление и автоматизация
«Говорим BPM — подразумеваем процессное управление»: на протяжении десятилетий от ведущих BPM-консалтеров слышим дифирамбы по процессному управлению. До сих пор считается, что с BPM призван в организации заместить «древний и неэффективный» функциональный подход на «новый и прогрессивный» процессный. …
Теперь к Вашему «священному АСМ»
По Вашей ссылке:
Одни эксперты считают, что ACM это «Pidgin-BPM», примитивная версия BPM, решающая те же проблемы, что и BPM. «Серьезные специалисты», отдавшие годы BPMN, BPEL etc., принять такую концепцию ACM не готовы, максимум, на что они вынуждены идти — это считать ACM опцией, дополнительным «бантиком» к BPM.
И это в консервативной wiki! Только это уже говорит, что до практического инженерного понимания этой технологии (или алхимии) предстоит еще долгий путь.
Хорошо. Давайте на паре примеров поймем, что такое АСМ.
Маркетинг и рекламу читать не будем, определений тоже не нужно (алхимия же), только на простых примерах («на пальцах»).
Пример первый, система документооборота.
Я хочу согласовать договор. Есть стандартный конвейер согласования: Отдел 1, Отдел 2, Отдел 3 и т.д.
Все это прошито в Workflow. Я захожу в систему DocFlow, ввожу договор, атрибуты, вызываю преднастроенный шаблон Workflow (с заданными маршрутами) и жму «поехали». Каждому согласанту в соответствии с логикой шаблона даются поручения, выскакивают окошки, требуют заполнения нужных полей и т.п. Потом, когда все отжали нужные кнопки, мне прилетает «Готово». Это в Вашем понимании ВРМ?
Но вдруг в одном экземпляре процесса (согласования договора N) или «кейса» (как правильно?) что-то пошло не так, и договор отклонили, мне прилетает соответствующее сообщение с комментарием. Я читаю, сильно думаю и решаю, что это «нестандартная» ситуация и нужно отправить договор «Иванову», который вообще не участвует в штатном Workflow.
Я жму кнопку: выбрать Иванова и отправить ему договор, а после получения правок от Иванова далее продолжается алгоритм «штатного конвейера».
Это добавка уже реализует подход АСМ? Конечно, ведется архив кейсов, и любой «на моем месте» может вызвать базу знаний и посмотреть как в подобном случае (нештатной ситуации) кто-либо действовал.
Иной Вариант первого примера, когда у меня вообще нет преднастроенного шаблона (т.е. «неструктурированный процесс») и я вручную в DocFlow создаю последовательность поручений (по произвольному списку), прикрепляя файл договора, – это тоже АСМ?
Второй пример покажите на процессе «Управления инцидентами», как он работает в режиме ВРМ и как в режиме АСМ?
Иногда употребляют «Adaptive Workflow Management System» (Pega, Papyrus и др.) — это тоже АСМ? В чем отличие?
Да, что-то я отвлекся, долго не отвечал.
Нет, я его вообще не использую. Но понимаю, и может когда-нибудь он мне пригодится.
По-другому и не будет, идея единожды определить, что такое BPM (или EA, или SE, или что угодно) утопична. Люди не выведут единственный, «расово верный», «арийский» BPM. «Не возьмут его под козырек» и стройном шагом не пойдут в светлое будущее.
Ваш вопрос не к месту, не нужно подменять понятия.
Ну как-нибудь без BPM(N) обойдёмся, там такое не рисуют, так как выглядит это будет глупо, потому что динамическое создание поручений — это как раз не flow. Это как бы «ситуационное управление». На ACM это нарисовать можно, но лучше, чтобы было уже заложено как базовый элемент СЭД.
А пёс его знает, у меня же голова не резиновая. Но я вот вижу, что Вы представляетесь специалистом во всём. Но почему-то у Вас «смешались все краски», и Вы не видите разницы, что BPM, что ACM, что ЭВМ, какая к черту разница…
Еще меня терзают смутные сомнения, что Вы придерживаетесь точки зрения: «Есть мнение bipiem, и есть неправильные мнения».
но вот покушаться на «святыню»: АСМ – это «кощунство»! Верно?
Нет, я его вообще не использую. Но понимаю, и может когда-нибудь он мне пригодится.
Затем когда всем становится очевидно, что беседа идет на разных языках и совсем «о разных BPM» начинаются вопросы к докладчикам: так Ваша система – это же не ВРМ!
Затем достопочтенная публика задается вопросом: Что такое BPM? Час приводят «книжные» термины (цитаты из BPM CBOK, других «процессных библий») – подходящие на все случаи жизни, которые еще более образуют «BPM — кашу».
По-другому и не будет, идея единожды определить, что такое BPM (или EA, или SE, или что угодно) утопична. Люди не выведут единственный, «расово верный», «арийский» BPM. «Не возьмут его под козырек» и стройном шагом не пойдут в светлое будущее.
Вы про этот CASE?
Ваш вопрос не к месту, не нужно подменять понятия.
Пример первый
Второй пример покажите на процессе «Управления инцидентами», как он работает в режиме ВРМ и как в режиме АСМ?
Ну как-нибудь без BPM(N) обойдёмся, там такое не рисуют, так как выглядит это будет глупо, потому что динамическое создание поручений — это как раз не flow. Это как бы «ситуационное управление». На ACM это нарисовать можно, но лучше, чтобы было уже заложено как базовый элемент СЭД.
Иногда употребляют «Adaptive Workflow Management System» (Pega, Papyrus и др.) — это тоже АСМ?
А пёс его знает, у меня же голова не резиновая. Но я вот вижу, что Вы представляетесь специалистом во всём. Но почему-то у Вас «смешались все краски», и Вы не видите разницы, что BPM, что ACM, что ЭВМ, какая к черту разница…
Еще меня терзают смутные сомнения, что Вы придерживаетесь точки зрения: «Есть мнение bipiem, и есть неправильные мнения».
Я перепутал «Иной Вариант первого примера» и «Второй пример покажите на процессе «Управления инцидентами»».
Не внимательно прочитал, ладно, потом отпишусь, спать надо идти.
Не внимательно прочитал, ладно, потом отпишусь, спать надо идти.
Но я вот вижу, что Вы представляетесь специалистом во всём. Но почему-то у Вас «смешались все краски», и Вы не видите разницы, что BPM, что ACM, что ЭВМ, какая к черту разница…
Потому и смешались, что это «краски алхимиков». Про «специалиста» — странно звучит, «специалиста по алхимии»? Скорее критика современной алхимии.
Вообще, сложно представить специалиста по такому списку:
A list of ALL ENTERPRISE FRAMEWORKS (and Modeling Tools)…
Если хотя бы из этой таблички в номинациях "Body: of Knowledge:" — есть люди, которые могут во всех них хорошо ориентироваться, то им нужно составить перекрестный «путеводитель» и вообще я бы с интересом почитал их статьи об «этой паутине» из «одного и тогож».
Только каждый обычно огораживает отдельную «делянку для бизнеса» и ее «осваивает» (монетизирует), особо «не мешая» другим.
«хВОК», но «БУК» звучит более созвучнее и точнее: часто вообще люди считают что там «на конце» — «book», что по смыслу так и есть.
В указанном списке еще много чего нет, например, нет того же хваленого BPM CBOK.
Составители из Pragmatic Enterprise Consulting, видимо поняв «все многообразие» (всю высоту маркетинговой пирамиды) споткнулись уже на 941 ступеньке и вообще бросили составлять список:
Last updated: 22 February 2013 (941 Frameworks and Modeling Tools)
Если все это было бы действительно так практично, то в этом можно (и нужно) было бы разобраться. Пока же там очень много маркетинга и «налитой воды», дублирования (каждую БУКу дублирует масса «внебучных» аналогов), а сделано почти все это под «маркетинг», «консалтинг», «сертификатинг» и другие продажи.
Хотя, для «видимости» иногда добавлены правильные подходы. Я же за то, чтобы как раз оставить рациональное зерно, но «вытряхнуть» весь маркетинг и домыслы.
Насколько я понял на примере BPM CBOK они пишутся примерно так: собрали группу известных авторов, даже с противоположными взглядами, и дали написать каждому «по чуть-чуть», в итоге получается БУКа из категории письмо «дяди Федору из Простоквашино».
Еще меня терзают смутные сомнения, что Вы придерживаетесь точки зрения: «Есть мнение bipiem, и есть неправильные мнения».
Точнее так: есть
— современная алхимия (как далекий прототип аналогичной науки);
— критика критиков этой алхимии (в т.ч. от bipiem);
— направления к превращению «алхимии в химию».
Одно из направлений — совсем простое: публиковать описания ЕА, каталоги процессов и т.п.
Причем не только — публиковать все это, т.е. «результат» (желательно с цифрой затрат), но и сами проектные подходы: практические методики (на основе которых был получен результат), проблемы при описании ЕА, ход реализации проектов и т.п.
Простой пример: где хоть одна практическая теория \ методика как идентифицировать бизнес-процессы предприятия и составить каталог его процессов? «Воды» и общих рассуждений — много, но «практического» — абсолютный ноль (хочется ошибаться, приведите ссылки на исключения).
В итоге, уверен, выяснится, что результативность проектов и подходов — крайне низкая, а развитие направления ЕА\ВРМ (SE в меньшей степени, они чуть далее продвинулись) в целом, находится примерно на этапе «самолетостроения до братьев Райт».
Примерно как первые конструктора — пилоты:
… порыв ветра сломал крыло его последнего планёра, в результате чего Лилиенталь упал с высоты около 17 м, получив перелом позвоночника. Он умер на следующий день, его последними словами были: «жертвы должны быть принесены»
История авиации
Только в нашем случае, все эти «эксперименты» ведутся не системно и с явной целью «заработать» даже на неудачах (как отдельное высокодоходное бизнес-направление), но главное «безобразие», в большинстве случаев, все это ведется за наш счет (налогоплательщиков).
Практически отсутствует обмен опытом на основе фактов и реальных (проектных) артефактов, т.е. только пиар и домыслы.
В отличие от современных алхимиков, пионеры авиации:
Также как и Лилиенталь, он документировал всю свою работу и фотографировал её результаты, кроме того, он вёл переписку со многими энтузиастами авиации со всего мира.
там же
Открытость — это пол дела, но очень важная.
Далее предстоит методологическая обработка результатов внедрений и т.п., потому что:
Однако большинство этих усилий было обречено на неудачу, так как они разрабатывались любителями, которые не имели полного понимания проблем, …
История авиации
Так же как и самолетостроение, наука «предприятие-строение» станет «взрослой» (станет наукой).
Сейчас гуру позиционируют свои ЕА\ВРМ «технологии» как полеты в космос, с соответствующей стоимостью своих услуг и «методичек».
Это «предприятие-строение» будет настольной книжкой для проектировщиков — «корпоративных и домашних» архитекторов холдингов, МСБ и даже домохозяйств.
Для предприятий будут аналогичные «аэродинамика» и «сопромат» и т.п., которые будут предельно точны и научны, возможно, эти знания также будут оформлены в «ВОК» с прежними названиями, но главное — новые БУКи в отличие от современных, станут практичными. Собственно об этом я говорил уже много.
По примерам ВРМ \ АСМ
Я не понял Ваши примеры, просьба дать пояснения к схемам (видите, туповат, а Вы говорите что «представляюсь специалистом во всём»).
Кроме того, что с моими примерами (документооборот)? Они правильно показывают различие ВРМ \ АСМ?
Также напомню, что, к сожалению, без ответа остался (пример ЕА):
Вроде все подробно, но Теряюсь в догадках, «что делать».
Если нет больше сил доделать начатое описание «Домашнее домохозяйство», то хотя бы изложите (обобщите) что было Вами сделано, что не хватает. И как это «доделать», желательно в формате «для чайников».
Кроме Вас никто вообще ничего не предложил конкретного (несмотря на обилие хваленых БУКов), поэтому «вся надежда на Вас».
Ответ случайно добавил как новую цепочку комментариев. См. 19.01.18 в 23:41
Системная инженерия, ЕА, ВРМ – должны когда-нибудь стать настоящей наукой и инженерией, точно также как и «коды Хэмминга». Это должен быть предельно формализованный аппарат, позволяющий формализацию требований («хотелок»), проектирование, проверку качества и точности исполнения изделий класса «система».
Неважно, какая это «система»: АСУ, включая, АСУ войсками, АСУТП или государственные информационные системы, «электронное правительство», или целое «предприятие» (ЕА), включая, домохозяйство, бизнес (ИП, МСБ, «корпорат»), государство.
Кстати насчет государства — иногда у меня, как системотехника, действительно руки чешутся бросить все и податься в президенты одного из государств — неудачниц, чтобы начать делать "Систему Управления Государством 2.0". Ведь даже с моим базовым набором знаний видно, когда какие-либо государственные процессы просто не функционируют, когда винтики тупо стоят не на своем месте и крутятся в разные стороны, когда сделано чересчур сложно или забюрократизировано.
Короче много чего с точки зрения построения систем можно было бы в государстве оптимизировать, перенять опыт, но, к сожалению, также с опыта системотехника видно, что Запорожец в Мерседес не переделать никак, а легче все разрушить и разработать полностью новое, но это к сожалению никак не провернуть.
Кстати насчет государства — иногда у меня, как системотехника, действительно руки чешутся бросить все и податься в президенты одного из государств — неудачниц, чтобы начать делать «Систему Управления Государством 2.0».
Вы не волнуйтесь, даже если и станете президентом, то Вам все равно в нашей стране (думаю и в других тоже) ничего не дадут сделать.
Лучше давайте «снизу» вместе делать SE \ EA \ BPM высокоэффективным инструментом и добавим им «серебряную пулю и волшебную таблетку»
Или хотя бы очистим их от управленческих и маркетинговых «причуд». Первый шаг — раскрытие тайн алхимиков и обзор «платья короля», т.е. публикация проектов SE \ EA \ BPM.
Вместо своей президентской программы, лучше составьте framework своего домохозяйства, как я предлагал здесь:
3 Конкурс на описание «household architecture»
Я не понял Ваши примеры, просьба дать пояснения к схемам (видите, туповат, а Вы говорите что «представляюсь специалистом во всём»).
Кроме того, что с моими примерами (документооборот)? Они правильно показывают различие ВРМ \ АСМ?
Задача «ИВАНОВУ НА ПОДПИСЬ» добавлена динамически в результате обработки ситуации «Отклонен». Произошла как бы рефлексия кейса, это не соответствует принципам BPM, в котором процесс не может изменить сам себя.
Ключевая разница:
- BPM требует спроектировать процесс заранее.
- ACM (Адаптивный кейс-менеджмент) позволяет изменять кейс в процессе работы.
Управление инцидентами
За основу возьмем информацию отсюда, я не специалист по службе поддержки, но там написано то, что я о ней знал и представлял. Процессный подход там нормально разрисован, повторять его не буду.
Первичный вид с подходом ACM, представлена ниже:
Только не нужно говорить, что это одно и тоже. Конечно и там, и там нарисованы одни и те же действия. Нужно понимать, что оба похода (BPM и ACM) решают задачу, просто один процесс центричный, а другой данные центричный.
Второй выход (из «Уведомление второй линии поддержки») не нужно рисовать, это я ошибся.
Дайте прямую ссылочку на описание сей нотациы.
Это Case Model Management and Notation (CMMN). Замечание: нужно понимать, что: ACM — концепция, CMMN – нотация.
Идею адаптивности понимать и реализовать можно по-разному. В Вашем понимании это будет выглядеть так: Разные алхимики будут говорить: «Вот это ACM, а это нет».
Идею адаптивности понимать и реализовать можно по-разному. В Вашем понимании это будет выглядеть так: Разные алхимики будут говорить: «Вот это ACM, а это нет».
Прям бальзам на душу. Очень понравилось, полностью согласуется с моим опытом.
Может быть несколько примеров приведете из опыта. Без фамилий и явок, а «все совпадения — с реальными событиями и лицами — случайны» и т.п.
Многим будет интересно.
Многим будет интересно.
Хм, надо попробовать, подумаю. Тот же NDA.
Достаточно всего лишь уточнить: Все персонажи являются вымышленными, любые совпадения с реальными людьми и событиями чистая случайность.
Вот пример, как можно обходить NDA через сказки и мультики:
Считаем бизнес-процессы. Введение
Там тоже реальные примеры, тоже запрещенные к разглашению через NDA.
Вот пример, как можно обходить NDA через сказки и мультики:
Считаем бизнес-процессы. Введение
Там тоже реальные примеры, тоже запрещенные к разглашению через NDA.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рассуждения вокруг системотехники и комментарии к «Ричард Хэмминг: Глава 28. Системная Инженерия»