7-8.10 в Ижевске пройдет конференция http://uic.dev - широкая конференция для всех специалистов в ИТ: разработчиков, аналитиков, дизайнеров, руководителей проектов, HR и всех остальных, на ней много направлений.
Я буду рассказывать улучшенный, еще более систематизированый доклад про то, как на самом деле нужно прорабатывать НФТ, чтобы это не «в стол».
P.S. У меня есть промокод на скидку, пишите в личку если надо.

Что такое Цифровизация бизнеса? Чем отличается от Автоматизации бизнеса (замена человека машиной)?
В проектах "Автоматизации" на моей практике всегда одновременно с заменой человека машиной происходило попутная перестройка бизнес-процесса, при котором значимо улучшалось качество. Так где же граница? Давайте поразмышляем на эту тему. А в комментах я напишу то определение, которое у меня получилось

Вопрос в аудиторию. Ощущение, что не хватает удобного инструмента

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

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

"Клиент, когда приходит за самовывозом заказа, передает данные для идентификации заказа и идентификации себя, как получателя заказа продавцу". Это модель взаимодействия сверху, без определенного функционального дизайна.

Далее мы определяем как функционально это возможно - предлагаем функциональные конструкции

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

После выбора конструкции, модель взаимодействия преобразуется в модель с определенным функциональным дизайном, например:
"Клиент, когда приходит за самовывозом заказа, передает QR код с зашифрованным алгоритмом RSA номером заказа и пин-кодом для идентификации заказа и идентификации себя, как получателя заказа продавцу, который сканирует, убеждаясь в подлинности"
(тут можно заметить, что не определен дизайн c1 уровня - в какой конкретно системе будет это работать и уровень инфраструктуры - конкретно сканирование будет в сканер+комп или ТСД или телефон).

Проектируйте системы путем декомпозиции на подсистемы, а далее переходите к проектированию подсистем. Сейчас до меня дошло, то раньше пытались декомпозировать ИТ-систему на классы, воспринимая их как подсистемы (давайте делать диаграммы классов UML). А дальше пришел SOA/ микросервисный подход в обоих из которых предполагается деление системы на простые ИТ подсистемы. Каждая подсистема больше чем один класс (обычно) и для ее проектирования достаточно сделать модели структур данных/взаимодействий/доступов/компонтент/размещения и пр, но не нужно проектировать классы. UML диаграммы классов ушли в историю… Или кто-то реально на проектах их использует по назначению (именно как классов в языке программирования)?

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

Слайды презентации с WAW. Удалось сделать связанный аналитический процесс и структуру документацию, по взаимоувязки аспектов системных уровней. Как сверху вниз, так сверху вниз. Объединяющий системный анализ и продуктовый анализ. В перезентацию все не влезло, поля узкие... )