В этот четверг, в 20-00 буду повторять доклад + проведем дискуссию на тему "а как на самом деле нужно прорабатывать НФТ". Ссылку кину в комменты в четверг

Фото с UIC 2024.
Конференция была довольно слабая. Зато познакомился с несколькими замечательными людьми, пообщались в кулуарах.

Через 7 минут начинаем про НФТ: https://meet.google.com/gdu-vpzg-vpu

Теперь на RuTube. https://rutube.ru/video/31a3d002163929ec4dac500af3c9709f/?r=wd. С момента доклада уже многое что переосмыслил , новая версия в процессе

Welcome на ЛАФ25.
Расскажу про методику поиска проблем/задач при цифровизации параллельных, множественно протекающих бизнес-процессов (как частный, но интересный случай задачи композиции моделей взаимодействий).
P.S. Мне дали промокодик, если что (в личку)

Сталкивались ли вы при автоматизации/цифровизации бизнес-процессов с
1. проблемами использования списков требований, как основного инструмента анализа и проектирования?
2. невозможностью проверки чужих ТЗ на оптимальность принятых решений?
3. Знаете ли вы методику решения этих проблем?
Если ответы Да-Да-Нет, то welcome.
В этот четверг вечером расскажу про методику анализа и проектирования, рассматриваемую как процесс конструкции, трансформации, детализации и пополнения моделей систем разных системных уровней и аспектов.
Доклад с WAW вырос до серии выступлений, это первая серия.
https://sistemnyy-podkhod.timepad.ru/event/3336143/

С чего начинается проект? с бизнес - требований (говорили они). Что дальше делает аналитик - выясняет зачем нужны бизнес-требования, как они будут использоваться, для решения какой задачи. Оптимальна ли решена эта задача, не нужно ли строить более оптимальное решение. Стейкхолдер уже заякорился на решение и сложно его убеждать, что стоит поискать альтернативы. (5 почему помните? спрашивать, пока заказчик не взбелениться...)

Вы видите проблему?

Если вы начинаете с ноля и еще нет бизнес-требований вы пойдете таким-же путем? Или может быть начнете собирать задачи и проблемы и вместе со стейкхолдерами строить их решения и оттуда получать информацию, что же нужно для ИТ системы, без сопротивлений и проблем?!

Процесс - это система? Судя по определению - да. Значит проектируется он исходя из "требований" и ограничений, так?
Строятся функциональная и конструктивная модель. Смотришь на карты процессов - явная функционально-конструктивная модель.
А где же "требования"?
И тут вчера щелкнуло. Это же DoD. Вам так не кажется?

Аналитики больше не нужны, говорили они. Достаточно продакта и разрабов, говорили они. ... Но что то пошло не так (ссылка на вакансию в комменте)

А вот и запись выступления на UIC24 подьехала. Более системный взгляд на проектирование "НФТ" (точнее на потребности и модели обеспечения качества). https://vkvideo.ru/video-184504774_456239164

А накидайте моделей ИТ системы, которые встречаются вам в проектах. У меня есть гипотеза о том, что все модели вытекают из задач функционального и конструктивного дизайна системы и ее использовани, моделей обеспечения качества, композиций этих моделей и моделей других точек зрения. Хочу проверить гипотезу (может есть еще что). На каждый вариант модели я обязуюсь указать - решением каких задач она является.

Welcome. Кто не смог на ЛАФ. Обсудим

🎤 Бесплатный вебинар от спикера ЛАФ:
Проектирование функциональных моделей для параллельных процессов

На ЛАФ 2025 Евгений Скориков представил доклад «Декомпозиция и композиция функциональных моделей при цифровизации бизнес-процессов на практике в аспекте множественности и параллельности». Он решил доработать материал с учетом ОС и собственной оценки. Обновленная версия будет представлена в формате вебинара.

Будет особенно полезно тем, кто проектирует модели автоматизации и цифровизации бизнес-процессов и сталкивается с множественными и параллельными потоками. Существующие нотации отображают параллельность, но не фокусируются на поиске задач, возникающих при этом. Важно уметь системно их выявлять.

Подробнее с материалами можно ознакомиться здесь.

👤 Евгений Скориков — главный архитектор компании-интегратора AWG. 24 года в ИТ: системный и бизнес-анализ, разработка, тестирование, менеджмент в цифровизации ритейла.

📅 Дата: 17 июля (четверг)
⌛️ Время: 19:00 (МСК)

📝 Зарегистрироваться можно по ссылке

Запись доклада. Народу понравилось, после обкатки получилось довольно просто на самом деле. https://www.webursitet.ru/all_trainings/1752418603.html

Статья про мультиресурсный аналих процессов готова: https://habr.com/ru/articles/937062/

На стачку 2 октября! Приглашаю на воркшоп-викторину, будем тренироваться в мультиресурсном концептуальном анализе бизнес-процессов. https://spb25.nastachku.ru/lp/proekt-1/speeches/vokshop-viktorina-po-multiresursnomu-kontseptualnomu-analizu-biznes-protsessov

Вопрос в аудиторию: Логическая структура данных превращается в физическую структуру данных (структуру хранения в какой-нибудь СУБД). Или не превращается?
До сих пор сталкивают с тем, что некоторые аналитики верят, что логическая структура всегда превращается в физическую.
А можете накидать примеров, когда не превращается?
Тут логическая структура - структура данных, в рамках которой происходят взаимодействия с внешним окружением.
Физическая структура - структура хранения данных в выбранной СУБД.

Приехал в Питер. Люди здесь по другому угрюмые. Более одухотворенно угрюмые )

Какие же бывают дебилы бизнесмены/дизайнеры ... Рефлексируя над своими мучениями выбора раскладушки с матрасом (на балкон), хочется немного выпустить пар.
Матрац 7 см, наполнитель Hollcon - вот что пишут они.
Мне не нужен матрац 7 см, наполнитель Hollcon. Я не понимаю, что такое 7 см и что такое Hollcon.
Что мне нужно? 7 см, наполнитель Hollcon - это конструкция, выполняющее функцию "поддерживать горизонтальное положение тела" с каким то количественными показателями качества "распределение давления на разные зоны тела такое-то".
Если аналитики спросят меня "какая тебе нужна функция, с какими показателями качества" - я не отвечу. Так и бизнес не может адекватно ответить на вопросы какая функция ему нужна (хватит собирать функциональные требования, в самом деле...)
Функция и количественные показатели качества - это уже результаты функционального и количественного дизайна того, как закрыть потребность.
Потребность - это не "плохо сформулированное бизнес-требование" (ау, авторы iso 29148, когда до вас дойдет JTBD).
Это проекция моделей использования (или лучше взаимодействия).
Мне нужно комфортно спать, у меня рост 173, вес 74 кг. Что нужно для этого, какое распределение давлений, какое положение тела - изучайте медицину, изготовители раскладушек с матрасами. И указывайте как и почему мне будет комфортно, какие ограничения вашего решения, для людей с какими параметрами. Дайте ввести эти параметры и покажите степень комфорта.
Рационально мыслящий клиент не выбирает товар, он (мучительно) ищет то, что откликается на его потребность. Доказательно откликается. Узнавая "свой" среди "чужих" - и радуясь "ну наконец-то"
Да, не все выборы рациональны, (эмоциональный, социальный, экономический аспекты для кого то важнее). Но если вы принимаете решение о одной карточке, то в одной карточке нужно соединить разные представления (универсализация дизайна) для разных аудиторий. Или делайте несколько карточек (принимайте осознанное решение о специализации/универсализации).
А вот вам - интересно детальнее узнать, как происходит преобразование моделей при проектировании? (использований в потребность, потребность в функциональный дизайн, и далее конструкция - конструктивный дизайн) ?