Раскладываем по полочкам
Вероятнее всего в собранной информации будут пересекаться правила, процессы, что-то связанное с законодательством, специфичные аспекты, которые важно учесть и так далее.
Чтобы это всё не превратилось в кашу, нам нужно продумать, какая структура будет удобна для работы с этой информацией.
📌 Мы можем рассматривать информацию, опираясь на бизнес-процессы компании:
- Какие данные задействованы в процессе, в каком виде приходят на вход, что с ними происходит в рамках процесса и что получается на выходе.
- Кто и как задействован в этом процессе. Тут будет здорово понимать организационную структуру компании или той части компании, с которой нам предстоит работать.
- Какие правила, стандарты, законы ограничивают этот процесс.
- Какие метрики и ожидаемые показатели применяются к процессу.
- Какая автоматизация задействована в процессе.
- Какие проблемы существуют в процессе по мнению разных заинтересованных сторон.
📌 Если мы исследуем ПО без привязки к процессам какой-либо компании, то за основу можно взять пользовательские истории, варианты использования или известные нам пользовательские пути.
Часто функциональность 1С, которую нужно исследовать, не выглядит интуитивно понятной. Нужно знать что, как, в какой последовательности и с какими предварительными настройками нужно сделать, чтобы получить желаемый результат. Этот самый результат может стать нашей отправной точкой для систематизации информации.
Например, чтобы получить результат Х, нам нужно:
- Выполнить настройки.
- Назначить пользователю права доступа.
- Добавить данные, необходимые для прохождения пользовательского пути. Например, сотрудников, номенклатуру и т.д.
- Выполнить в системе действия 1, 2,3.
💬 Почему не подсистемы, функциональные блоки и объекты конфигурации
Вокруг них может быть крайне сложно построить структуру для систематизации информации. Как исключение тут можно выделить рабочие места, различные помощники и прочую функциональность, которая изначально проектировалась под конкретные пользовательские сценарии.
Какой бы вы ни выбрали подход, важно, чтобы он помогал собрать целостное представление из ранее собранной информации.
Как можно задействовать визуализацию для лучшего понимания
Нам важно, когда это происходит?
Этот вопрос поможет понять, нужно ли нам видеть последовательность событий. Будь то шаги процесса, интерфейсы, логика передачи и получения данных, мы можем универсально применять для визуализации шкалу времени, она же timeline.
На ее основе строятся многие процессные диаграммы, поэтому мы легко можем прочитать их слева направо или сверху вниз.
Но есть и более сложные варианты, когда нужно читать и слева направо и сверху вниз, двигаясь или по определенной логике процесса, или по потокам данных. Например, диаграмма в нотации BPMN с несколькими дорожками или диаграмма последовательности UML.
📌 Познакомиться с BPMN можно на сайте Stormbpmn. Промотайте в самый низ страницы и обратите внимание на блок «Изучайте».
📌 Посмотреть и попробовать освоить диаграммы UML можно на сайте worldskills:
- Диаграмма последовательности
Даже если вы еще не знакомы со всеми этими инструментами, вы можете применить шкалу времени и упростить себе задачу комплексного понимания уже сейчас:
- Расставить события или действия в порядке слева направо и показать связи стрелками.
- Найти зависимости одних событий от других.
- Указать примечания к действию. Например, какой создается документ или какие применяются правила.
Если сделать следующий шаг, то, как отправную точку для погружения в процессное моделирование, можно освоить блок-схемы. Со временем вы можете столкнуться с ограничениями в визуализации, так как в блок-схемах небольшой набор символов. Тут можно начать кастомизировать блок-схемы дополнительными символами из других нотаций, либо изучить нотацию с более богатым набором символов.
👥 Также по шкале времени располагают события при визуализации пользовательского и клиентского опыта, посредством карты пользовательских историй (USM), карты пути клиента (CJM), карты пути пользователя (UJM) или карты сервиса (Service Blueprint).
Для их применения важно разобраться в назначении каждого инструмента, чтобы не начать делать лишнюю работу. Создание подобных карт может занять много времени, а если сделать их сне по правилам, то это может не только не принести пользы, но и навредить.
Например, ошибкой будет построить UJM на основе своего представления о пути пользователя или USM на основе своих гипотез о потребностях пользователей, а потом показать команде, как достоверную информацию.
Почему?
Данные инструменты предполагают, что мы пообщались с пользователями или иным способом исследовали их опыт и потребности. Если мы этого не делали и приводим только наши предположения, то это нужно обозначить в явном виде. Проектирование и разработка, которые опираются только на наши предположения, могут вылиться в необходимость переделать все с нуля.
📌 Для погружения в этот подход рекомендую посмотреть:
- Запись лекции про исследование клиентского опыта
- Запись вебинара «Основы для аналитика в 1С и не только»
👤 Отдельного внимания заслуживает User flow - это пользовательский сценарий или, иначе говоря, путь пользователя, который мы можем изобразить в разных вариантах:
- Блок-схемы - показывают пути пользователя для понимания общей логики его взаимодействия с системой.
- Wire flow - блок-схемы + wireframe - экранные формы с низкой детализацией.
- Screen flow - детально проработанные экранные формы, из которых можно сделать прототип.
Почитать про User flow и посмотреть пример можно тут.
Визуализация, для которой не нужна шкала времени
Подчиненность и иерархия
👥 Самый простой пример - оргструктура. С ней мы можем работать на разных уровнях: компания в целом, уровень отделов, уровень сотрудников. В зависимости от того, что нам важно понять, мы можем изучить имеющуюся или самостоятельно составить оргструктуру с необходимой степенью детализации.
Просто, когда структура иерархическая или матричная. В этом случае нам будет легко показать подчинение на любом уровне.
Сложнее, когда структура частично иерархическая и частично матричная. Тут одной схемой не обойтись. Например, если два отдела имеют разные варианты оргструктуры, то лучше показать отдельно каждый, а на общей схеме остановиться на уровне отделов и не показывать детально подчиненность внутри.
Почитать про оргструктуры и посмотреть примеры можно тут.
📂 Еще один пример - справочники в 1С. Например, номенклатура, которая группируется по различным признакам.
Если салон красоты попросит нас навести порядок в их номенклатуре, то крем для лица мы отнесем в группу «Уход за кожей лица», группу «Уход за кожей лица» отнесем в группу «Уходовые средства», группу «Уходовые средства» отнесем в группу «Товары».
Мы можем сделать это сразу, но лучше предварительно согласовать такую иерархию. Для этого можно изобразить структуру с помощью ментальной карты.
Больше узнать про справочники в 1С и посмотреть, как выглядит иерархия можно тут.
💬 Ранее мы уже рассматривали Objective Chain из RML, которая помогает показать, какое влияние использование функциональности должно оказать на метрики и показатели. Например, на выручку, скорость выполнения или затраты. Она тоже представляет собой иерархию.
Объекты и их связи
В каких случаях нас интересует как один объект связан с другим, без аспекта подчинения и иерархии?
💬 Например, когда мы хотим изобразить взаимодействие разных систем. Это можно сделать на примитивном уровне, рисуя системы в виде квадратиков, а связи - в виде стрелочек. Например, из квадратика «1С:Бухгалтерия» мы передаем данные об оплатах в квадратик «Сайт».
А можно пойти на более сложный уровень и изучить нотации. Например, нотацию C4. В данном случае нужно выбирать тот вариант, который:
- Позволит в нужный срок осознать логику
- Будет понятен другим, если это необходимо
В случае, если в компании есть стандарты применения нотаций, то можно отталкиваться от них.
👥 Когда мы хотим показать пользователей и их возможности, мы можем использовать:
- Матрицу CRUD и матрицу ролей и прав, чтобы показать доступ к данным и действиям с ними. Подробнее о них можно почитать тут и тут.
- Диаграмму вариантов использования UML, чтобы показать, какая функциональность каким пользователям доступна. Подробнее о ней можно почитать тут.
💬 Когда мы хотим показать взаимосвязь целей, которые нужно достичь и решений/функциональности, которую мы реализуем, можно использовать модель бизнес-целей или Business Objective Model. Она помогает лучше понять, что от нас ожидают заказчики и убедиться, что мы делаем необходимое и не делаем лишнее. Например, что мы не делаем функциональность, которая на самом деле не решает ни одну из обозначенных проблем.
Подробнее о ней можно почитать тут и посмотреть тут.
💬 Есть еще очень большое количество ситуаций, когда мы можем визуализировать что-то с помощью иерархии, матриц и фигур со стрелочками. Главное - подобрать подходящий для текущего контекста вариант, который поможет показать необходимое, не запутает, не усложнит восприятие и будет понятен всем, кто будет обращаться к вашей визуализации.
