Прошу прощения, пока всё не осилил, но прямо с самого начала, про терминологию. Не понял, почему все ссылки на CBOK (к своему стыду, даже не припомню, чтобы слышал о нём), и не используется BABOK? Моделированием, изучением бизнес-процессов занимается бизнес-анализ. В т.ч. и терминологически. В BABOK, насколько помню, разделены бизнес-процессы и бизнес-функции. Есть бизнес-правила (не надо, пож-та, "административных регламентов", это другое). Используя BABOK, часть затронутых тут проблем была бы решена естественным путём
Предположу, что не взлетело потому что не было осязаемых (измеряемых) целей. Надо ж понять, сколько стоит держать в этой системе актуальное инфо, и сколько стоит не держать, а обходится текущими (или ещё какими-то другими) процессами в компании.
Второй момент. Если прикинули и сказали "да", то дальше надо соблюдать соглашение о новых процессах. Это не просто дисциплина и регламенты. Это такая же часть работы, как и всё остальное, что далеко не все понимают ("не царское это дело - доки заполнять...").
Повторюсь, важен конечный результат, а не то, что сеньоры-помидоры ломаются от n% времени на процедуры
Сначала была связь "один ко многим", где у одной машины был один владелец, и у одного владельца много машин. Но со временем эксплуатации системы в продакшн оказалось нормальной ситуацией, что иногда два человека приезжают обслуживать одну машину
Какое отношение имеет сколько человек приехало обслуживать машину к количеству владельцев машины? Я не понял
Возможно, пропустил при чтении, но так и понял, где в статье таблетка для исключения фейлов из примеров? Только знание, в т.ч. с помощью стейкхолдеров/консультантов, домена знаний. Ещё немного может помочь здравый смысл. Как тут можно другим, волшебным образом "сделать модель БД гибкой" под эти примеры, тоже не понял. Вся модель БД - это ровно то, что предусмотрел аналитик после выявления всех (вымерших, текущих и будущих) сущностей и их зависимостей. Откуда тут какая-то другая "гибкость"?
Извините, но такая интерпретация неверна. Не имеет значения, что там хотел сказать автор (какую скорость он показывает: физического интерфейса, передачи файла или любую другую). Он численно описывает один параметр двумя способами. Без вариантов
Мне кажется, ответ уже заложен в слове "идеал". В этом и состоит вся польза руководителя, чтобы он настраиваил и управлял процессами так, чтобы было как можно ближе к принципиально недостижимому идеалу
Судя по описанию, компонент в системе - это микросервис, стало чуть понятнее. Не ушло главное моё непонимание. Вы проектирует якобы для одного компонента только на том основании, что в нём будут проходить большинство процессов. При этом затронуты другие компоненты - это очевидно из приведённых US/UC.
Т.е., вместо того, чтобы описать пользовательскую функциональность как взаимодействие всех компонентов между собой, вы описываете как взаимодействие одного компонента со всеми остальными. Полное понимание процессов по конкретной пользовательской функциональности теперь только внутри одного компонента. Получаем, что все описания почти рандомно размазаны по компонентам. Каждый компонент теперь не понимает, что и зачем вот этот API в нём делает - надо идти к потребителю. А потребителей может быть более одного. То же самое, зачем компонент внезапно использует какой-то метод другого компонента. Теперь надо бегать по всей системе, искать "ответственный" компонент, чтобы сложить пазл.
Если это так, то это полный кошмар для аналитика. Зачем вкладыватьверхнеуровневые (бизнес) артефакты в компоненты - не понимаю. В компонентах должен содержаться исключительно системный анализ. Описание логики, данных, API - всё то, что касается работы исключительно данного компонента
Ларчик просто открывается. Невозможно полностью проанализировать предметную область (я про реальные области/системы) так, чтобы спроектировать для неё идеальную логическую структуру. Элементарное доказательство - невозможно предсказать завтрашние изменения предметной области. И даже вчерашние изменения, потому что вы сегодня просто не имеете знаний о том, что было вчера. В реальном мире невозможно учесть всё.
Кстати, для меня тоже пару лет назад стало неприятным откровением, что не получится легко и непринуждённо использовать СНИЛС как идентификатор человека
Не совсем понял. Какая последовательность действий СА? Сначала текстовое описание методов, затем контракт OpenAPI или наоборот? Если наоборот, откуда СА будет брать инфо в процессе описания контракта - держать в голове?
Наверное, я ещё не дорос до понимания энтерпрайзных решений. Вижу
мы поэтапно рассмотрим, как формировалась система управления знаниями
и приготовился в статье по этим самым этапам наблюдать формирование системы. Какие-то довольно общие абзацы, модное "единая цифровая среда" и т.п. И бац (выделение моё):
мы выбрали для импортозамещения российскую платформу TEAMLY, которая отвечает всем этим требованиям
Т.е. вся ваша система выродилась в покупку софта, который даже адаптировать не пришлось, потому что оно отвечает всем требованиям? Ещё. Я не верю, что готовый сторонний сложный продукт прямо на входе "отвечает всем этим требованиям". Чудеса прям. Что-то тут не так, мутная статья какая-то. (наивно) Ах, неужели рекламная?!
Много пересечений содержания и фото этого поста с https://dubikvit.livejournal.com/180556.html
Там, пожалуй, будет поболее
Прошу прощения, пока всё не осилил, но прямо с самого начала, про терминологию.
Не понял, почему все ссылки на CBOK (к своему стыду, даже не припомню, чтобы слышал о нём), и не используется BABOK? Моделированием, изучением бизнес-процессов занимается бизнес-анализ. В т.ч. и терминологически. В BABOK, насколько помню, разделены бизнес-процессы и бизнес-функции. Есть бизнес-правила (не надо, пож-та, "административных регламентов", это другое).
Используя BABOK, часть затронутых тут проблем была бы решена естественным путём
Предположу, что не взлетело потому что не было осязаемых (измеряемых) целей.
Надо ж понять, сколько стоит держать в этой системе актуальное инфо, и сколько стоит не держать, а обходится текущими (или ещё какими-то другими) процессами в компании.
Второй момент. Если прикинули и сказали "да", то дальше надо соблюдать соглашение о новых процессах.
Это не просто дисциплина и регламенты. Это такая же часть работы, как и всё остальное, что далеко не все понимают ("не царское это дело - доки заполнять...").
Повторюсь, важен конечный результат, а не то, что сеньоры-помидоры ломаются от n% времени на процедуры
Какое отношение имеет сколько человек приехало обслуживать машину к количеству владельцев машины? Я не понял
Возможно, пропустил при чтении, но так и понял, где в статье таблетка для исключения фейлов из примеров?
Только знание, в т.ч. с помощью стейкхолдеров/консультантов, домена знаний. Ещё немного может помочь здравый смысл.
Как тут можно другим, волшебным образом "сделать модель БД гибкой" под эти примеры, тоже не понял. Вся модель БД - это ровно то, что предусмотрел аналитик после выявления всех (вымерших, текущих и будущих) сущностей и их зависимостей. Откуда тут какая-то другая "гибкость"?
Извините, но такая интерпретация неверна.
Не имеет значения, что там хотел сказать автор (какую скорость он показывает: физического интерфейса, передачи файла или любую другую). Он численно описывает один параметр двумя способами. Без вариантов
Это по какой системе исчисления?
Нет.
В какую функцию какого компонента входит US "Поставить диагноз, получить рекомендации от ИИ"?
Мне кажется, ответ уже заложен в слове "идеал".
В этом и состоит вся польза руководителя, чтобы он настраиваил и управлял процессами так, чтобы было как можно ближе к принципиально недостижимому идеалу
Судя по описанию, компонент в системе - это микросервис, стало чуть понятнее.
Не ушло главное моё непонимание. Вы проектирует якобы для одного компонента только на том основании, что в нём будут проходить большинство процессов. При этом затронуты другие компоненты - это очевидно из приведённых US/UC.
Т.е., вместо того, чтобы описать пользовательскую функциональность как взаимодействие всех компонентов между собой, вы описываете как взаимодействие одного компонента со всеми остальными. Полное понимание процессов по конкретной пользовательской функциональности теперь только внутри одного компонента. Получаем, что все описания почти рандомно размазаны по компонентам. Каждый компонент теперь не понимает, что и зачем вот этот API в нём делает - надо идти к потребителю. А потребителей может быть более одного. То же самое, зачем компонент внезапно использует какой-то метод другого компонента. Теперь надо бегать по всей системе, искать "ответственный" компонент, чтобы сложить пазл.
Если это так, то это полный кошмар для аналитика.
Зачем вкладыватьверхнеуровневые (бизнес) артефакты в компоненты - не понимаю.
В компонентах должен содержаться исключительно системный анализ. Описание логики, данных, API - всё то, что касается работы исключительно данного компонента
Пользовательская функциональность затрагивает, как правило, несколько компонентов архитектуры. У вас эпики - компоненты.
Где вы формулируете US, UC для этой функциональности, если у вас самый верхний уровень - компонент?
Как внутри одного компонента можно делать US, если она обычно затрагивает несколько компонентов?
Как можно внутри компонента описывать БА, если он охватывает весь продукт (несколько компонентов)
Ларчик просто открывается. Невозможно полностью проанализировать предметную область (я про реальные области/системы) так, чтобы спроектировать для неё идеальную логическую структуру.
Элементарное доказательство - невозможно предсказать завтрашние изменения предметной области. И даже вчерашние изменения, потому что вы сегодня просто не имеете знаний о том, что было вчера. В реальном мире невозможно учесть всё.
Кстати, для меня тоже пару лет назад стало неприятным откровением, что не получится легко и непринуждённо использовать СНИЛС как идентификатор человека
Не совсем понял. Какая последовательность действий СА?
Сначала текстовое описание методов, затем контракт OpenAPI или наоборот?
Если наоборот, откуда СА будет брать инфо в процессе описания контракта - держать в голове?
Тогда что там делает союз "и" в предложении и множественное число "показатели"?
В общем, я ещё не разучился читать по-русски
Если показатель теплового сопротивления - высокий , то это - плохая термопрокладка
Всё, что я хотел показать и сказать, сделал в 1-м комменте. Извините, нет времени на перефразирование
Наверное, я ещё не дорос до понимания энтерпрайзных решений.
Вижу
и приготовился в статье по этим самым этапам наблюдать формирование системы.
Какие-то довольно общие абзацы, модное "единая цифровая среда" и т.п. И бац (выделение моё):
Т.е. вся ваша система выродилась в покупку софта, который даже адаптировать не пришлось, потому что оно отвечает всем требованиям?
Ещё. Я не верю, что готовый сторонний сложный продукт прямо на входе "отвечает всем этим требованиям". Чудеса прям. Что-то тут не так, мутная статья какая-то. (наивно) Ах, неужели рекламная?!
Пока не выполнена валидация требований, в т.ч. зависимости, за API браться не надо. И не надо будет возвращаться к требованиям при проектировании API
Что не так?
Было бы замечательно формулировать заголовки, исключающий двоякое прочтение
В BPMN - моделируем BPM
В BPMS - применяем разработанную модель BPM
Верно?