Как донести здравый смысл до заказчика. Инструменты архитектора

05.08.22

Архитектура

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

Расскажу про узкоспециализированную тему – про инструменты архитектора, которыми я пользуюсь в повседневной жизни.

 

Часто в работе возникают ситуации, когда бизнес начинает продавать какую-то идею. «Ребята, нам нужно сделать вот такое». Они рассказывают, как они это видят, но в результате обсуждение затягивается и тратится огромное количество времени.

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

Расскажу, в чем заключается мой способ.

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

Если вы начинаете чувствовать, что обсуждение буксует, – рисуйте картинку.

 

Версионируйте картинки.

Очень удобно хранить картинки в Git, используя для этого специальные текстовые форматы – это позволяет отслеживать изменения, коллективно работать над какими-то схемами и диаграммами.

Рисовать картинки – обычно уныло. Если на бумажке или на маркерной доске рисовать ещё как-то удобно, но в цифровом виде все это выравнивать, соединять стрелочками – довольно уныло.

Поэтому нужны удобные инструменты.

 

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

  • Mind Maps,

  • BPMN,

  • Archimate

  • и на сладкое – PlantUML.

 

Mind Maps. Объясняем самому себе

 

Самый простой инструмент – это Mind Maps или «ментальные карты». Он помогает объяснять не кому-то, а самому себе, такое тоже иногда бывает.

Если есть какая-то идея или проект, но не знаете с чего начать, пользуйтесь «ментальными картами», их еще называют картами ума или картами памяти.

Mind Maps – это очень старый инструмент, им многие пользуются. Его удобно использовать в качестве аналога листка и ручки, когда в голове нужно зафиксировать еще неоформившиеся мысли, разложить их по полочкам, пока не улетели.

 

Ментальная карта выглядит как иерархическое дерево.

На слайде – мой план поездки на конференцию Инфостарта. Когда я понял, что еду в Питер, сделал план. Это же целый проект: что нужно не забыть сделать, что купить, о чем рассказать в докладах и так далее. Куча мыслей о том, как поехать на Инфостарт, все они друг-друга вытесняют и роятся в голове, постоянно выпадая из фокуса внимания.

Поэтому берём Mind Maps и рисуем проект по пунктам.

  • сначала надо себя как-то доставить туда – создаем ветку «Доставка»;

  • добавляем билеты в обе стороны – можно файлы приложить, чтобы не потерялись;

  • добавляем гостиницу – сохраняем документы на номер в отеле;

  • продумываем, что с собой брать, какая будет в это время погода в городе;

  • работаем с темами докладов – добавляем тезисы и т.д.

История начинает оформляться в дерево, в карту памяти.

 

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

Например, проект по запуску кофейни – с чего начать, что не забыть, как подготовить. Какие-то темы, подтемы и т.д.

 

 

Для рисования таких карт я использую программу FreeMind.

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

Чем хорош FreeMind?

  • Он позволяет работать с деревом полностью с клавиатуры, без использования мыши, а просто на горячих клавишах. Мысль сразу из мозга переносится в файл.

  • Ты можешь записывать эти ветки дерева, укрупнять темы, подтемы, выстраивать связи – все с клавиатуры. Подумал – записал.

  • Инструмент минималистичный, практически черно-белый. Но легко и удобно позволяет делать все, что нужно – приложить файл, нарисовать связь, работать с иерархией.

FreeMind, «приложение с бабочкой» – на мой взгляд, лучшее для работы с картами памяти.

 

BPMN 2.0. Выясняем пробелы в постановке задачи

 

Следующий шаг – когда мы сами себе объяснили и хотим работать с заказчиком. Например, к нам приходит заказчик и рассказывает о бизнес-проекте или бизнес-идее, и предлагает сразу делать.

Как запускать такой проект, и как работать с заказчиком, когда ты чувствуешь, что бизнес-процесс ему самому до конца не понятен? Заказчик примерно понимает, что хочет, но не до конца.

 

Для этого я использую инструмент BPMN – Business Process Modeling Notation.

Это нотация, некий стандарт рисования и представления бизнес-процессов на языке бизнеса.

BPMN работает строго, как язык программирования. Это не просто какие-то схемы бизнес-процесса, а схемы, которые могут запускаться на выполнение. Для этого в платформах Apache Camunda и Activity есть специальные инструменты. Например, там есть сервер, который занимается оркестрацией всех интеграций: если пришло письмо с определенным текстом, нужно вызвать такой-то сервис, а если с другим текстом – другой сервис. И все это выражено в терминах бизнеса и реальных процессов реального мира. В этом мощь BPMN – там отражается процесс всего бизнеса, а не та малая его часть, которая происходит внутри компьютеров.

Это классная вещь и супермощное средство для поиска недопродуманных бизнес-процессов.

 

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

У него исторически есть список клиентов в старых системах, а сейчас его компания внедрила новую CRM, и он хочет профили всех клиентов свести туда.

Он хочет открывать одно окно и видеть: что человек у него покупал, когда, какие договоры заключались – все исторические данные свести в новую CRM.

 

В этой ситуации понятно только текущее состояние – что сейчас есть системы с историческими данными, есть недавно внедренная CRM, есть бардак в данных.

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

Процессная часть непонятна, вы видите только статику «хотелки», поэтому всегда анализ задач нужно вести от процесса. Это must have. Если вы не обсуждаете свои задачи от процесса реального мира, то, скорее всего, на проект вы потратите гораздо больше времени, потому что у вас отсутствует ось времени в анализе, а без нее вы рано или поздно окажетесь в ситуации «ой, а тут мы забыли, что мы для этого звоним Леночке и она делает распечатки и рассылает клиентам».

 

Заказчиков можно долго спрашивать, как у них всё происходит, как они всё делают, кто чем занимается и т.д.

А можно сразу взять Bizagi Modeller, которым пользуюсь я, и нарисовать желаемый процесс с точки зрения реального мира. Не системы, которые участвуют, а именно конкретный порядок действий в разрезе конкретных исполнителей – шаги реального мира.

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

 

Давайте разберем эту задачу подробнее. Действующие лица процесса:

  • менеджер по продажам, который работает в CRM (приложение на React);

  • клиент – юридическое лицо, которое создает заказы в личном веб-кабинете, написанном на Java. В своей учетной записи клиент видит, когда и что заказывал, когда ему отгрузили товар или когда этот товар будет отгружен;

  • и есть оператор склада, который отгружает эти заказы, он это делает, например, в «Управление торговлей 11» – мы можем только предполагать, на чем она написана.

 

Если этот довольно простой процесс начать исследовать с точки зрения BPMN, можно узнать много интересного о том, что происходит в компании.

BPMN – это простая нотация, у ее немного ключевых узлов:

  • начало процесса;

  • конец процесса;

  • какие-то развилки или наоборот, сведение процессов;

  • ожидание наступления каких-то событий;

  • синие квадраты – это уже какое-то конкретное действие руками или с помощью автоматизации.

Немного элементов позволяют описать практически все бизнес-процессы.

 

Начинаем исследовать.

Нам нужно свести записи клиентов в одну базу. А что такое клиент? Кого мы считаем клиентом, и как он появляется в фирме?

Начинаем расспрашивать и выясняем, что есть CRM-система, где появляется лид после холодного обзвона. Это значит, что сначала клиент заходит на менеджера по продажам. Менеджер ведет его в CRM, но это все еще лид, а не клиент.

Как мы понимаем, что это наш клиент? Когда он с нами заключит договор, тогда он и станет клиентом.

 

Так и фиксируем:

  • Работа по воронке продаж.

  • Проверка – начал ли клиент с нами работать.

  • Если начал, заводим запись как клиента.

Процесс начинает немного выстраиваться.

 

Опрашиваем заказчика дальше.

Как появляется учетная запись клиента в личном кабинете? Мы его в CRM завели, уговорили подписать контракт, но как он получает свою учетную запись – логин, пароль в личный кабинет?

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

Мы понимаем, что здесь используется ручная работа, значит, можно сделать какую-то автоматизацию и интеграцию.

 

Выясняем дальше.

Клиенту сделали личный кабинет, он там заводит заказы, смотрит статистику и т. п., а как УТ на складе будет это обрабатывать и отгружать? УТ-шке ведь тоже нужны знания о контрагентах. Начинаем обзванивать, разговаривать и выясняем, что из этого личного кабинета раз в сутки выгружается Excel с новыми контрагентами и загружается в УТ.

Этот Excel, конечно, тоже можно улучшить и автоматизировать но основная проблема не здесь.

Беда в том, что в личном кабинете договороцентрическая модель. Т.е. если какое-то крупное юридическое лицо работает с нами по нескольким договорам с разными условиями, у него будет несколько учетных записей в личном веб-кабинете. Например, у крупного заказчика несколько центров финансовой ответственности. Оба заключили договор с нами, но по отдельности друг от друга, они друг про друга даже не знают.

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

Такая же ситуация в УТ – там тоже партнероцентрическая модель в отношении юридического лица.

Т.е. модели данных личного кабинета и УТ уже перестают стыковаться, а мы хотим их данные сводить вместе. В УТ нам нужно создать не на каждый договор из CRM+ЛК одного контрагента, а создать одного партнера и к нему уже договоры. И решения о том, как это состыковать у бизнеса нет. В этом месте на схеме можно рисовать облачко с надписью «МАГИЯ».

Так проясняются нестыковки в бизнес-процессах – с фиксацией каждого действия на пути от заказа к выручке.

 

Выясняя процесс «как он есть», мы сразу же зарисовываем его в строгом виде.

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

В результате мы:

  • нашли открытый вопрос – как приводить систему к единой модели;

  • нашли какие-то ручные операции, которые можно исключить и автоматизировать;

  • нашли странные интеграции через Excel.

В такой нотации очень удобно обсуждать задачу.

 

 

Решая эту задачу, мы завели отдельный сервис MDM, который занимается чисткой данных:

  • когда в CRM появляется клиент, его данные сливаются в MDM;

  • там выясняется, какому юрлицу принадлежит договор – существующему или нет, определяется юрлицо и его договор;

  • и в таком виде данные раздаются в целевые системы потребителей (в УТ и ЛК).

  • попутно удалили массу дубликатов данных

Все стали счастливы.

Вывод: обсуждать проекты нужно с точки зрения процессов, а процессы прорисовывать сразу в BPMN. Тогда на обсуждении экономится куча времени.

 

Archimate. Многослойная архитектура

 

Еще один инструмент, который мне сильно помогает, – Archimate.

 

Архитектуры бывают разные – бизнес-архитектуры, архитектуры решений, архитектуры приложений, интеграционные архитектуры. Еще туда накладываются английские термины: Enterprise Architecture и Solution Architecture. Совершенно непонятно, что под этими словами скрывается и какие должностные обязанности у человека, который будет эти архитектуры разрабатывать.

Чтобы добавить ясности в эти термины, архитектурная группа TOGAF – это такая группа, которая консолидирует лучшие практики по IT в целом в мире – выпустила спецификацию Archimate, которая переводится как «друг архитектора».

Согласно этой спецификации, архитектура делится на слои:

  • слой бизнеса;

  • слой технологии;

  • слой инфраструктуры.

 

Для описания слоев спецификация Archimate предлагает несколько простых общих блоков: сервис, процесс и функция.

 

Описание архитектуры зависит от того, с какой стороны мы хотим смотреть на этот архитектурный объект.

Если мы описываем слой бизнеса, у нас есть:

  • клиент – Business Actor;

  • менеджер по продажам – тоже Business Actor;

  • некий процесс, в котором они работают – Business Process

  • при этом задействуются бизнес-службы – Business Service – склад и личный кабинет.

 

Этот склад и личный кабинет работают на основе какого-то софта. Описание слоя софта выглядит так:

  • управление складом WMS организовано на УТ;

  • работу личного кабинета тоже обеспечивает ряд каких-то сервисов – для аутентификации, веб-интерфейса, внутренние сервисы и т. д.

Т.е. есть некий бизнес-процесс, который поддерживается вот таким софтом.

 

Этот софт работает на железяках (в нотации Archimate железяки показываются зеленым цветом) – WMS работает на кластере 1C, есть Kubernetes, а между ними Kafka.

То есть бизнес-процесс поддерживается софтом, который работает на железках.

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

 

 

Сейчас самое интересное – то, что мне нравится больше всего.

 

PlantUML. Рисуем текстом в «Блокноте»

 

PlantUML – это вещь, которую я полюбил с первых моментов ее использования. Она позволяет рисовать кодом в блокноте самые различные диаграммы, схемы, которые привычны людям – прямо в Visual Studio Code. И тут же видеть результат.

 

Почему это клево?

  • Потому что рисовать картинки муторно: выравнивать стрелочки; думать, где разместить – левее, правее, выше; центрировать какие-то квадраты относительно друг друга. Все это муторно и отвлекает. Это нужно отдать на софт. Пускай железо думает, где какой кубик рисовать, а мне надо смысл донести.

  • Нам нужно быстро нарисовать идею. За пять минут в PlantUML можно накидать сложные диаграммы и уже их обсуждать. Обсуждая картинку, вы экономите часы рабочего времени.

  • PlantUML поддерживается в Visual Studio Code и во многих других программах.

  • Этот фрагмент программного кода можно вставить почти куда угодно

 

На слайде показан пример диаграммы последовательности для интеграции 1С с сайтом.

В Draw.io устанешь рисовать такую диаграмму: пока выровняешь, пока стрелку нарисуешь, пока привяжешь…

Не надо этого делать. Нужно обсуждать смысл – кто, кому, когда и что посылает. Такая диаграмма зарисовывается за 10 строк кода за 1-2 минуты.

Сразу можно обсуждать и кидать письмо коллегам, говорить: «Вот такая схема вас устраивает или нет?». Удобно.

 

PlantUML поддерживает большое количество нотаций: последовательности, алгоритмы, статусные переходы, компоненты. Их огромное количество.

Из плюшек – документация к PlantUML на русском языке.

 

Диаграмма статусных переходов состояния

 

Еще один пример из жизни. Заказчики любят придумывать для документов в системе статусы, фантазировать, что им нужно учитывать в системе много статусов – до нескольких тысяч.

Под статусом может подразумеваться все что угодно – события, состояния или переход между ними. Просто слово «Статус» звучит весомо и красиво.

Как только вы слышите от заказчика: «Нам нужны статусы», сразу рисуйте диаграмму переходов состояний. Её ещё называют STD. Это позволит отсечь ненужные фантазии, минимизировать количество требуемых статусов и сделать их более осмысленными.

 

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

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

При этом названия статусов абсолютно вторичны.

 

Опять же, берем PlantUML, пишем статусы заказа, и получается диаграмма.

Обратите внимание на статусные переходы:

  • сначала у нас есть телефонный заказ в статусе «черновик»;

  • потом мы набрали корзину – получили статус «ожидает оплаты»;

  • потом, если заказ в течение пяти дней не оплачен, он переходит в статус «не оплачен» – к нему подключается менеджер;

  • клиент обещал оплатить – опять же статус «ожидает оплаты» и так далее.

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

Нарисовали десяток строчек и получили диаграмму, которую можно обсуждать легко и весело. А главное – недолго и эффективно.

 

Эта история может расширяться:

  • В PlantUML с помощью препроцессора можно создавать собственные синтаксические или графические блоки – глифы. Допустим, мы хотим, чтобы у нас рисовался синий квадратик с надписью 1С.

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

  • С помощью директивы «!include» мы можем подключить библиотеку наших собственных компонентов и использовать ее вместе с коллегами.

  • Поскольку VS Code – это расширяемый редактор, там можно сделать подсказку через точку, чтобы VS Code подставлял блоки диаграмм самостоятельно. Это возможно, но я еще не пробовал.

 

Коллективная работа. Библиотеки компонентов, версионирование

 

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

  • Во-первых, все они основаны на текстовых форматах. Нотации BPMN и Archimate – это XML, PlantUML – это маленькие текстовые скрипты.

  • Все это можно складывать в Git. Например, когда мы прорисовывали все наши потоки интеграций по компании, мы работали втроем – складывали схемы PlantUML и присылали друг другу пул-реквесты: «Ты прорисовываешь склад, а ты прорисовываешь другое». Каждый рисовал свои компоненты, а потом мы мержили это в какой-то один документ.

  • Этот документ потом экспортировался в PDF, HTML и так далее. Т.е. на основании скриптов PlantUML мы сгенерировали набор красивых PDF. С таблицами и рисунками.

При этом мы работали в Git – присылали друг другу пулл-реквесты и ревьюили. Код-ревью картинок – это весело.

 

Какие преимущества мне дает визуализация процессов при затянувшемся обсуждении:

  • Это быстрое получение результата.

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

  • С картинкой мы решили это за час.

  • BPMN позволяет находить дыры и неоптимальности в текущих процессах, потому что привносит в бизнес-анализ ось времени – кто, когда, что и почему делает.

  • Не просите заказчика рассказать о процессах, лучше сразу вместе с ним рисуйте – так вы сэкономите огромное количество времени.

 

Напоминалка:

  • Если хочется зафиксировать самому себе какую-то неоформившуюся мысль, создавайте карты памяти – с помощью FreeMind, XMind, FreePlane. Мне нравится FreeMind за его минималистичность и возможность работы чисто с клавиатуры, не отрывая рук от кнопок.

  • Для BPMN я использую Bizagi, но можно пользоваться Camunda или VS Code. Там есть плагин, вы его ставите, графически создаете файл BPMN, накидывая элементы в VS Code, а на выходе получается XML-файл. Очень удобно.

  • Archimate – это многоуровневый редактор Archi от TOGAF.

  • Все остальное – это PlantUML.

    • Диаграмма последовательности – кто, кому, когда, что посылает при интеграции.

    • Слышите слово «статус», открываете PlantUML и рисуйте переходы, потому что половина статусов не нужна. Важны не статусы, а дуги между статусами. Именно они приводят к статусам.

    • Нотация С4 – удобный способ представления архитектур. Там всего два глифа – человек и квадратик, больше вообще ничего архитектору не нужно. Никаких стрелочек, черных ромбиков, белых ромбиков, включение «один ко многим». Все это – атавизмы прошлого века.

    • В PlantUML огромное количество диаграмм, все документировано на русском на сайте plantuml.com и все редактируется в виде текста.

 

Что почитать

  • https://plantuml.com

  • mellarius.ru/architecture – классный сайт с огромным количеством материалов по архитектуре, по-моему, его автор даже 1С-ник.

  • www.archimatetool.com – информация об Archimate.

  • bpmn2.ru

  • camunda.com – это оркестратор бизнес-процессов. Он позволяет гибко менять интеграции в микросервисной среде. Это классный инструмент, но требует внедрения, потому что это серверы и приложения, а не просто рисовалка. Рекомендую изучить, в этом что-то есть.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14299    0    ASchekachev    37    

55

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4185    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10665    0    biimmap    79    

75

Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика

Архитектура Бесплатно (free)

Считается, что аналитику для работы на проекте достаточно уметь строить бизнес-процессы в одной-двух популярных нотациях. Но это не так, потому что работа аналитика гораздо разнообразнее и не ограничивается рисованием схем. О том, какие инструменты пригодятся аналитику и помогут ему сделать свою работу комфортной и удобной, на конференции Infostart Event 2021 Moscow Premiere рассказала руководитель отдела сопровождения финансового учета компании «Самокат» Анастасия Штей.

23.06.2022    6488    0    ashtey    1    

41

Путь покупателя интернет-магазина (Customer Journey) с использованием УФМТП

Архитектура Управленческий учет Бесплатно (free)

Недавно у меня вышла статья под названием «Универсальная функциональная модель торгового предприятия (УФМТП) в нотации IDEF0». И одно из пожеланий читателей было пояснить подробнее, как я лично пользуюсь этой моделью и как вообще ее можно применять на практике. В этой статье я выполню просьбу читателей. И на примере взаимодействия покупателей с интернет-магазином продемонстрирую практическое применение этой модели.

12.05.2022    2005    0    raiml    2    

5

Универсальная функциональная модель торгового предприятия в нотации IDEF0

Архитектура Управленческий учет Бесплатно (free)

Из чего состоит предприятие? Какие функции основные, а какие нет? В данной статье вы найдете ответ на этот и другие вопросы. Модель, построенная на основе опыта бизнес-консультанта с использованием нотации IDEF0.

12.05.2022    6698    0    raiml    4    

7

Технология вялых проектов

Управление проектом Бесплатно (free)

Не все ж такие молодцы.

11.05.2022    5307    0    1c-intelligence    49    

41

Решение детективных задач

Архитектура Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Пробуем систематизировать методы решения детективных задач

25.08.2021    5492    0    1c-intelligence    31    

63
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. AlexanderEkb 25 08.08.22 07:13 Сейчас в теме
Спасибо за статью очень понравилась. Как раз то, что мне сейчас нужно. Позволю себе привести ссылку, для общего развития, на похожую статью на основе советской программы ДРАКОН изобретённой в 80-х годах для Бурана https://drakon.su/drakon-sxemy_aleksandra_araptanova, тоже общение с закзчиком, тоже построение схем. Там используется чуть более лаконичная схема построение безнес-логики, на мой взгляд. Хотя бы взять вот это правило: "Чем правее — тем хуже", или правило "Шампура" - мне нарвится.
user1266336; Chernik; acces969; +3 Ответить
2. ardn 622 08.08.22 09:20 Сейчас в теме
3. Petr54-ru 90 08.08.22 13:50 Сейчас в теме
Мне больше всего интересно, кто эти прошаренные ребята на стороне заказчика, которые понимают BPML и UML диаграммы? ИТ- директора и бизнес-аналитики?

Я когда 20 лет назад начинал в системной интеграции, мне мой директор, выпускник ММФ НГУ, "бил по рукам" и требовал описалова всего и вся - исключительно простым человеческим языком в MS Word. Тогда утверждалось, что бизнес никаких диаграммок понять не в состоянии. Я так до сих пор и работаю. Мои заказчики - это небольшой бизнес, несколько десятков пользователей, филиалы. Общаюсь на уровне нанятых директоров и собственников, никто ничего кроме форматированного текста не понимает.

Уровень какой - РЖД, Росатом, Газпром?
user776428; +1 Ответить
4. AlexanderEkb 25 09.08.22 05:49 Сейчас в теме
(3) Уровень обычного человека. Вот пример схемы BPML из медицины, её может понять любой.
Прикрепленные файлы:
5. Petr54-ru 90 09.08.22 06:19 Сейчас в теме
(4) Уровень обычного человека - всегда и везде говорить, что он все понял, а косяки будут потом.

Я в универе учил алгоритмическую нотацию Бэкуса-Наура, поэтому для меня эта диаграммка понятна сразу, за других людей я бы не был так уверен.

Хотелось бы некоего внятного критерия, типа если у представителя заказчика степень MBA имеется, то можно смело его диаграммками донимать - или сразу поймет, или переспросит.
6. AlexanderEkb 25 09.08.22 07:55 Сейчас в теме
(5)
нотацию Бэкуса-Наура
Тем не менее их используют везде. Даже в районную больницу придти они там развешаны.Что делать при том и том-то, для посетителей больнице.
7. Petr54-ru 90 09.08.22 08:08 Сейчас в теме
(6)
Тем не менее их используют везде. Даже в районную больницу придти они там развешаны.Что делать при том и том-то, для посетителей больнице.


Я вашего оптимизма не разделяю. С новогодних каникул до недавнего времени был завсегдатаем наших районных поликлиник - сперва квоту получал на операцию, потом пред операционное обследование проходил. Там для контингента проблема записаться на прием по единому телефону "122", а вы про диаграммки.
EliasShy; Yashazz; +2 Ответить
12. flex81 66 18.09.22 19:01 Сейчас в теме
(4) Это не BPML это схема нотации ДРАКОН))
15. AlexanderEkb 25 03.01.23 19:24 Сейчас в теме
(12) Да, вы правы. Я тогда ещё не понимал, что есть BPML. Я Я хотел сказать, ч т
16. AlexanderEkb 25 03.01.23 19:28 Сейчас в теме
(12) Да, вы правы. Я ещё не доконца понимал тогда разницу BPMP схем от других нотаций. Но Дракон схемы - это один из лучших, на мой взгляд, вариантов описания процессов, который будет понятен бизнес заказчику.
9. Evil Beaver 8107 09.08.22 13:24 Сейчас в теме
(3)
Мне больше всего интересно, кто эти прошаренные ребята на стороне заказчика, которые понимают BPML и UML диаграммы


Не надо учить их нотациям, надо пройтись с ними за ручку по той схеме, которую вы им предлагаете, отсечь бред и выявить слабые места. Кстати, аналитики (если они аналитики, а не знакомая одного друга, которой надо практику пройти), как правило, владеют BPMN и "блок-схемами" Бэкус-Нуара (будь они здоровы)
10. Petr54-ru 90 10.08.22 06:55 Сейчас в теме
(9)
Не надо учить их нотациям, надо пройтись с ними за ручку по той схеме, которую вы им предлагаете, отсечь бред и выявить слабые места. Кстати, аналитики (если они аналитики, а не знакомая одного друга, которой надо практику пройти), как правило, владеют BPMN и "блок-схемами" Бэкус-Нуара (будь они здоровы)


Я с самого начала за бизнес-аналитиков и ИТ-директоров не переживал.

Т.е. диаграммки в рамках проекта выступают как проектные артефакты, - создаются и используются в работе, но на руки заказчику не передаются? Или передаются?

Если заказчик лоялен, например - это внутренний проект компании, который выполняется своими силами, то можно много чего делать и не напрягаться особо. А вот если есть сомнения в лояльности заказчика, то "каждое ваше слово может быть использовано против вас".

На вопрос про уровень заказчка так и не ответили, заодно поделитесь своими соображениями относительно уровня лояльности.
11. Evil Beaver 8107 10.08.22 08:50 Сейчас в теме
(10) я работаю in-house и мой заказчик это бизнес-подразделения той же организации. Передавать ли артефакты, как часть проектной документации внешнему заказчику - не знаю. А они ему нужны?
Petr54-ru; +1 Ответить
8. Evil Beaver 8107 09.08.22 13:20 Сейчас в теме
Кстати, для рисования схем про 1С в PlantUML Дима Овчаренко сделал библиотеку глифов для 1С https://github.com/ovcharenko-di/1ce-icons-for-plantuml
13. Gaster 28.09.22 11:20 Сейчас в теме
Дайте пожалуйста ссылку на BPMN. Есть много разных версий, но не нашёл Вашу. Нужна цветная и Online.
14. Gaster 28.09.22 13:01 Сейчас в теме
(13) Вобщем нашёл что искал:

https://bpmn.io/ - Очень простой и быстрый вариант.

https://www.lucidchart.com/pages/ru - с условным форматированием и другими плюшками.
17. E-xcelsior 11.04.23 13:56 Сейчас в теме
Оставьте свое сообщение