Бизнес аналитика блок схемы

Где объяснять работу алгоритма и описывать бизнес-процессы.

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

Рассказываем о платформах с блок-схемами, которые вам помогут.

1. Creately

В сервисе есть библиотека шаблонов для разных отраслей (маркетинг, стратегия, продукт, IT, образование) и десятки диаграмм — например, схемы обработки данных.

Creately дает возможность проводить видеоконференции, оставлять комментарии и отслеживать изменения в схеме в реальном времени. Доступны экспорт проекта в форматы PNG, SVG и JPEG, а также функция перетаскивания элементов блок-схемы.

Среди клиентов сервиса — Intel, Netflix, NASA, Facebook, National Geographic.

Стоимость: от $5 в месяц (есть пробная версия для всех тарифов), до 3 сотрудников — бесплатно.

2. Miro

Сервис предлагает веб-доску с блок-схемами по 6 направлениям — для воркшопов, стратегий, мозговых штурмов, построения диаграмм, Agile-инструментов. Его можно использовать не только для схем, но и для презентаций и коммуникации с командой — есть аудио- и видеозвонки, а также режим демонстрации экрана. Кроме того, в Miro доступны канбан-доски и интеграция с сервисами Jira и Asana, Dropbox, Google Suite, Slack и Sketch.

У Miro более 20 млн пользователей. Среди них — компании Dell, Deloitte, Cisco.

Стоимость: бесплатно для 3 редактируемых досок. Платные тарифы — от $8 за пользователя в месяц.

3. Gliffy

Платформа помогает создавать диаграммы UML (Unified Modeling Language), диаграммы Венна и простые блок-схемы онлайн.

Плюс приложения — удобный интерфейс. Минус — в бесплатной версии все диаграммы остаются в открытом доступе.

У Gliffy более 16 млн пользователей. Он интегрируется с другими программами, включая Confluence, Jira Software и Jira Service Desk.

Стоимость: доступна бесплатная 14-дневная версия. Затем — от $4,99 за пользователя в месяц.

4. Edraw Max

Сервис предлагает 280 шаблонов в 4 направлениях: бизнес, дизайн, IT и «другое» (например презентации). Каждый тип диаграммы поставляется с коллекцией шаблонов.

Edraw Max можно интегрировать с PowerPoint, а также экспортировать проекты в различные форматы — Visio, PDF, Word, PPT, JPEG, HTML.

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

Среди клиентов — Apple, Amazon, Nike, Facebook.

Стоимость: пробная версия — 30 дней бесплатно, затем — от $8,25 в месяц.

5. Cacoo

Здесь меньше шаблонов, чем в других сервисах.

Cacoo позволяет создавать диаграммы базы данных ER. Их используют, чтобы проиллюстрировать взаимосвязь объектов в программном обеспечении.

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

Cacoo интегрируется с Google Диск и Google Docs, AWS, Adobe Creative Cloud, Slack, Dropbox, Visio.

Стоимость: от $5 за пользователя в месяц, бесплатная 14-дневная пробная версия.

6. Lucidchart

Это онлайн-приложение с версиями для Windows, Mac OS X и Linux. Одна из фишек сервиса — горячие клавиши.

У платформы есть функции наслоения. Их цель — создавать диаграммы внутри диаграмм. Кроме того, пользователи могут устанавливать ссылки на текстовые поля или блоки в диаграмме (они появляются только при щелчке по элементу). Схемы можно комментировать, отмечая коллег, чтобы те получали уведомления.

Lucidchart поддерживает Confluence, JIRA и JIVE, а также Google Cloud, и совместим с Microsoft Visio.

Стоимость: от $7,95 в месяц, также есть неограниченная по времени бесплатная версия (максимум 60 объектов для работы).

Источник: robotdreams.cc

Как мы делаем аналитику IT-проектов: прояснение требований

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

Vision/Виденье проекта

1. кто чего хочет
2. почему и зачем хочет
3. как должно быть устроено, чтобы всем понравилось
4. что нужно сделать, чтобы этого добиться

В Vision зафиксированы наиболее существенные требования, ограничения и приемлемые уровни качества.

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

Пример Vision

User Stories/Юзер сторис

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

Текст каждой формулировки — User Story — должен объяснять роль или действия юзера в системе, его потребность и профит, который он получит после того, как история случится.

К примеру: Как, , я , .

1. Они не описывают требования детально (то есть то, что система должна делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого).
2. Их относительно легко оценивать, поэтому можно быстро определить усилия, необходимые для реализации.
3. Они организованы в списки, которые легко упорядочить и переупорядочить по ходу поступления новой информации.

Именно на основании User Stories проводится дальнейший анализ.

Пример User Stories

Use Cases/Юзкейсы

Так же как и User Stories описывают, как пользователь должен взаимодействовать с системой, чтобы достичь конкретной цели. В чём же тогда отличие? User Story помогает определить задачу и намерение. А Use Cases не сообщают о задачах и намерениях, они более подробно фиксируют функциональные возможности.

Посмотрим на эти различия на примере гипотетической разработки обычного калькулятора.

Формулировка User Story может быть такой: «Я как пользователь хочу иметь возможность совершать математические операции, чтобы упростить механические расчеты».

А кейсы, соответствующие данной User Story, могут быть такими:

1. Ввести число
2. Добавить число
3. Отнять число
4. Разделить на число
5. Умножить на число
6. Подвести итог
7. Добавить результат в память
8. Очистить память
9. Показать число в памяти
10. Сбросить все
11. Отключить устройство

Пример Use Cases на проекте iFarm — AgroTech информационной системы

Инструменты для наглядного описания процессов, алгоритмов, взаимосвязей между сущностями

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

В таком случае мы можем столкнуться с реальными функциональными ограничениями на то, что мы можем сделать за адекватный срок. Например, API, которую нам предоставляет внешняя система, накладывает обязательства на реализацию функционала регистрации пользователя. Это могут быть определённые поля, параметры или условия, которые мы должны включить в запрос. Иногда технические ограничения накладываются и на пользовательский интерфейс. Чтобы разобраться в существующих ограничениях и с их учётом создать удобный функционал, нужно разобраться, какие существуют и какие должны быть реализованы интеграционные сценарии, нарисовать диаграмму компонентов или развертывания.

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

Описание сущностей

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

Список Entities

Диаграммы компонентов

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

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

1. визуализировать общую структуру исходного кода системы
2. многократно использовать отдельные фрагменты программного кода
3. представить концептуальную и физическую схему баз данных

В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты.

Диаграмма развертывания

Показывает инфраструктуру системы графически. Диаграмма отображает, как располагаются и соединяются сетевые устройства. С её помощью определяются сведения о компьютерах, обрабатывающих информацию, как они связаны друг с другом и какие дополнительные ресурсы (принтеры, модемы, маршрутизаторы и т. д.) должны быть задействованы.

Элементами диаграммы развертывания являются узлы, компоненты и связи между ними. Узел — это некоторый физически существующий элемент системы. В качестве узла могут рассматриваться компьютеры, датчики, принтеры, модемы, цифровые камеры, сканеры и т.д.

Диаграмма развертывания помогает более рационально распределить компоненты системы по узлам сети, от чего зависит в том числе и производительность системы. С её помощью можно решить вспомогательные задачи, например, связанные, с обеспечением безопасности.

Карта экранов

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

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

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

Блок-схемы

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

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

Блок-схема алгоритма платежей

Вайрфреймы

1. основные группы содержимого
2. информационную структуру
3. описание взаимодействия пользователя с интерфейсом и его примерную визуализацию.

1. Для первичного определения задач, если стейкхолдер по какой-то причине не может воспринимать текст.
2. Чтобы визуализировать интерфейс админки. Здесь в основном используются стандартные элементы, поэтому нам важно не то, как они выглядят, а какие именно нужны и как они работают.

Прототипы

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

Прототипы модуля «Мониторинг продавца» на проекте iFarm

Дизайн

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

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

Проработка дизайна экрана логина

Пользовательские инструкции

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

Заключение

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

Источник: spark.ru

Строим блок-схему на предприятии самостоятельно

Согласно основным документам, регулирующим порядок разработки и наличие на предприятиях пищевой промышленности системы ХАССП, одним из требований к предприятию является разработка и верификация блок-схем технологических процессов.

Более подробно с конкретными требованиями по блок-схемам вы можете ознакомиться в таких нормативных документах как ГОСТ Р 51705.1-2001 «Системы качества. Управление качеством пищевых продуктов на основе принципов ХАССП. Общие требования» и ГОСТ Р ИСО 22000-2007 «Системы менеджмента безопасности пищевой продукции. Требования к организациям, участвующим в цепи создания пищевой продукции».

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

Типы блок-схем

Блок-схемы в своем общем виде бывают трех видов:

1. Блок-схемы по приемке, размещению и хранению на складах сырья и упаковочных материалов. В них указывают требования и контролируемые параметры при входном контроле, а также, в зависимости от вида сырья – требуемые условия размещения и хранения.
2. Блок-схемы по подготовке сырья и материалов к производству. Здесь сырье проходит первичную (чаще механическую) обработку. Овощи чистятся, моются, нарезаются; замороженные продукты животного происхождения размораживаются, промываются и разделываются; сыпучие продукты, в случае необходимости просеиваются и так далее. Перечень сырья и выполняемых операций по подготовке к дальнейшим этапам производства довольно разнообразный и зависит от каждого конкретного типа предприятия, ассортимента и других факторов.
3. Блок-схемы по приготовлению (производству) блюд (готовой продукции) перед реализацией (отгрузкой) конечному потребителю. Все заготовки и полуфабрикаты, ранее подготовленные, собирают на таких схемах воедино и производят окончательный технологический процесс (тепловые и механические обработки, переработка, фасовка, смешивание, упаковка и маркировка, приемка по качеству и бракеражный контроль, реализация, отпуск или отгрузка). Всё очень разнообразно и зависит от конкретных задач и типа предприятия.

Все блок-схемы в системе ХАССП состоят из определенного набора операций, имеющих свой смысл и условные обозначения. Условные обозначения блок-схем представлены в таблице 1.

От теории к практике

Для создания наиболее понятной картины по построению блок-схемы мы возьмем рецептуру заправочного супа (борщ с капустой и картофелем) из Сборника технических нормативов (СТН) для общественного питания.

Первое, что нам необходимо знать для построения блок-схемы — это технология приготовления и входящее в состав блюда сырьё. Итак, вот наш список сырья:

— капуста белокочанная свежая;

— морковь столовая свежая;

— лук репчатый свежий;

— томатное пюре (паста);

— бульон или вода;

— специи (перец черный молотый/горошком, лавровый лист);

— растительное масло для обжарки и пассерования.

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

Блок-схема по приемке, хранению и перемещению сырья на производство

Данная схема состоит из трех основных операций (этапов):

1. Входной контроль
2. Выгрузка на склад
3. Хранение сырья (в зависимости от его типа)

Пример блок-схемы по приемке, хранению и перемещению сырья на производство

Так мы определяем, какие меры предпринимаем на входном контроле, как хранится и куда перемещается сырье после хранения.

Задайте свой вопрос экесперту ХАССП!

Блок-схемы по подготовке различных групп сырья к производству

Из БС1 все сырье перемещается на производство. Однако прежде чем овощи попадут в суп, они должны пройти соответствующую обработку, из подготовленного мяса должен быть сварен бульон. Воду для бульона тоже нужно подготовить соответствующим образом. Значит, нам необходимы следующие блок-схемы:

1. по подготовке овощей;
2. по подготовке мясного сырья;
3. по подготовке воды к варке бульона;
4. по варке бульона (в данном случае, она является подготовительной операцией перед варкой супа и должна расцениваться соответствующим образом).

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

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

Рис.2 Подготовка овощей к производству

Мясное сырье тоже нуждается в предварительной подготовке. подготовительные этапы берем из СТН. На Рис.3 представлена блок-схема по подготовке мясного сырья к производству.

Рис.3 Подготовка мясного сырья к производству

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

Рис. 4 Подготовка воды к производству

Да настоящего момента при составлении названий блок-схем подготовки мы использовали порядковые номера, начинающиеся с цифры 2 (2.1, 2.2, 2.3). Бульон можно использовать как самостоятельное блюдо, поэтому мы относим его к готовой продукции. Начиная с этой блок-схемы, мы будем присваивать порядковые номера, начиная с цифры 3 и далее – по количеству подгрупп наших блюд. Что это значит? Представьте, если бы у нас кроме бульона и супа было еще несколько видов блюд (например, салаты, блюда из мяса и птицы, блюда из рыбы, мучные кулинарные изделия). Названия наших блок-схем по приготовлению блюд выглядели бы примерно следующим образом:

-БС3 Бульон мясной;

-БС4 Супы заправочные;

-БС6 Блюда из мяса;

-БС7 Блюда из рыбы;

-БС8 Мучные кулинарные изделия…

На Рис. 5 представлена блок-схема по приготовлению мясного бульона.

Задайте свой вопрос экесперту ХАССП!

Блок-схема по приготовлению заправочного супа

Итак, все ингредиенты для борща прошли предварительную подготовку. Далее наша задача, используя технологию приготовления по СТН, собрать всё воедино, провести оценку получившегося блюда и проанализировать его на соответствие к предъявляемым требованиям качества. Нужно определить меры коррекции при несоответствии и отправить на реализацию потребителям.

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

• Кроме сырого картофеля и капусты в кипящий бульон необходимо положить пассерованный репчатый лук с морковкой, тушеную с уксусом и томатным пюре свеклу. Поэтому первый этап – предварительная термообработка овощей (пассерование и тушение). Предварительной она называется потому, что после нее будет еще одна – непосредственно варка супа.
• Берем подготовленный мясной бульон, закладываем в него сырую капусту, картофель, пассерованные и тушеные овощи. Назовем этап «добавление ингредиентов».
• Провариваем суп, доводим его до кулинарной готовности. В это же время добавляем соль, сахар, специи. Этот вид тепловой обработки последний перед подачей супа клиенту и носит название «окончательной термообработки».
• Перед тем, как подать блюдо клиенту, его необходимо оформить. Добавляем в порционную тарелку сметану, посыпаем зеленью. Этап назовем «оформление».
• Отбираем из сваренного объема контрольную порцию и проводим бракеражный контроль. Он включает в себя оценку органолептических показателей блюда: вкус, цвет, запах, внешний вид, форму нарезки ингредиентов, консистенцию и так далее. По результатам контроля выносится решение: если показатели качества в норме – отправляем блюдо на реализацию. В противном случае оцениваем степень не соответствия качеству и принимаем решение по корректирующим действиям: если присутствуют мелкие недочеты (недосол) – устраняем и отправляем на повторный органолептический контроль; если недочеты являются неустранимыми – испорченные (пережаренные) ингредиенты, влияющие на вкус, внешний вид и съедобность – утилизируем всю партию.
• Если мы решаем отправить блюдо на реализацию, то должны указать ее предельные параметры. Например, в данном конкретном случае мы должны обратиться к СанПиН 2.3.6. 1079 – 01 «Санитарно-эпидемиологические требования к организациям общественного питания, изготовлению и оборотоспособности в них пищевых продуктов и продовольственного сырья» и выяснить температуру подачи данного вида блюда, сроки и температуру реализации. Температура горячих супов при подаче не ниже +75°С. Супы могут находиться на мармите или плите не более 2-3 ч с момента изготовления при постоянной температуре не менее +75°С. Указываем данную информацию в нашем последнем этапе – реализация.

Рис.6 Блок-схема приготовления заправочного супа (борща)

Данную логику следует применять при построении блок-схем для любых этапов и видов производств. Для понимания рецептур (технологий изготовления) необходимо руководствоваться ТТК или СТН в общественном питании и ТИ (ТУ или СТО) в производстве. Все похожие блюда, для удобства, следует объединить в подгруппы и строить для них общую блок-схему.

Источник: haccp24.expert