Структурный анализ выявил — KPI назначен ошибочно. Отдел продаж занимался обработкой входящих звонков. Объем продаж складывался из количества звонков и качества их обработки. Первая составляющая этой формулы — количество звонков — зависела от других подразделений: рекламы, маркетинга и интернет-сайта. Наделение отдела продаж ответственностью за работу других подразделений приводило к деструктивной психологической напряженности и целевой дезориентации.
Цель: выявление границ процессов, корректная идентификация входов и выходов.
Источник данных: графические модели бизнес-процессов, описанные при функциональном анализе.
Структурный анализ выявляет два типа ошибок:
1. Ошибки целеполагания;
2.Несоответствия между полномочиями и ответственностью;
Такого рода ошибки могут быть как неумышленными, так и внедряться осознанно. Для исправления неумышленных ошибок достаточно их выявления. Для нейтрализации деструктивной борьбы за влияние и привилегии, необходимо участие в решении этой проблемы вышестоящего руководства.
Понятия | SADT
Вне зависимости от причин возникновения, эти ошибки ведут к некорректному выбору KPI. Мотивация на достижение некорректного KPI несет ряд крайне негативных последствий:
- Некорректный KPI жестко мотивирует менеджеров и исполнителей на умножение дефектов процесса и ведет к наказанию за реальное совершенствование. Это катастрофически снижает эффективность, дефекты процесса устойчиво воспроизводятся;
- Проведение функционального анализа теряет смысл — оно превращается в бесконечную «борьбу с симптомами»;
- Проведение план-факторного анализа становится или невозможным, или умножает исходную неэффективность;
О технологии анализа
Наиболее качественные результаты, при структурном анализе, дает методология SADT. При этом исходные модели требуют преобразования в нотацию IDEF0.
Стоит обратить внимание на то, что структурный анализ требует от аналитика профессиональных навыков, зеркально противоположных функциональному. На рынке труда большинство резюме, содержащие упоминание нотации IDEF0, подразумевают знание нотации, но незнание методологии, что для структурного анализа принципиально важно. Такая ситуация обусловлена непониманием его роли в управлении процессами и попытками аналитиков применить эту нотацию не по назначению – для функционального анализа – с закономерно провальным результатом.
При четком понимании целей и серьезном отношении к методологии, любой аналитик сможет освоить его за 2-4 недели. Под освоением подразумевается не только знание нотации и методологии, но практическое закрепление паттернов мышления, зеркально противоположных функциональному анализу.
Пример №1
На одном из проектов была поставлена задача — повысить показатели отдела продаж. Изначально этому отделу был назначен KPI «объем продаж», что на первый взгляд логично. На объем продаж была ориентирована и жесткая система мотивации — полностью отсутствовала окладная часть зарплаты, только процент с продаж.
Структурный анализ выявил — KPI назначен ошибочно.
Лекция 3: Методология структурного анализа и проектирования
Отдел продаж занимался обработкой входящих звонков. Объем продаж складывался из количества звонков и качества их обработки. Первая составляющая этой формулы — количество звонков — зависела от других подразделений: рекламы, маркетинга и интернет-сайта.
Наделение отдела продаж ответственностью за работу других подразделений приводило к деструктивной психологической напряженности и целевой дезориентации.
Исходный KPI «объем продаж», диктовал нечеткий способ достижения — «больше и лучше работать». К такой цели невозможно было применить план-факторный анализ.
Замена KPI на «процент обращений, завершенных сделками» открыл план-факторной разрез — «что повлияло на отказ клиентов от сделки». Далее, план-факторный анализ выявил 12 факторов (!), повышающих риск отказа клиента от сделки. Были внесены изменения в процесс, исключающие саму возможность проявления многих факторов и существенно сглаживающие негативные эффекты от оставшихся.
Смежные же подразделения, ответственные за привлечение клиентов, перестали зависеть от эмоциональной оценки руководителя и получили измеряемый ориентир для совершенствования работы – количество входящих звонков от потенциальных клиентов.
Стоит отметить, что жесткость системы мотивации — самостоятельный фактор. Подбираться он должен менеджером для каждого процесса индивидуально, так чтобы взаимодействие с работниками оставалось конструктивным.
Избыточное мотивационное давление, для достижения KPI, может привести к отрицательной селекции работников и разрушению рабочей этики в коллективе. Ответственные работники, не желающие вводить руководителей в заблуждение, или будут выдавлены с рабочих мест, или примут правила игры в ущерб интересам организации.
Пример №2
Центральным офисом были приняты меры по повышению эффективности техобслуживания сети платежных терминалов. Для технических специалистов был выбран KPI – количество выездов на обслуживание и ремонт. Далее, назначен жесткий норматив и крутая пропорция депремирования.
Впоследствии было выявлено, что 80% выездов приходится на перезапуск GPRS-модемов для восстановления связи с сетью интернет. Периодический обрыв GPRS-сессий обусловлен особенностями этой технологии.
Для восстановления связи, в терминалах предусмотрены специальные устройства — сторожевые таймеры, корректно работающие только в связке с соответствующим программным обеспечением. Это программное обеспечение отсутствовало в образах, записываемых на жесткие диски терминалов. Попытки качественного ремонта требовали больше времени на переналадку, вели к срыву «плана по количеству ремонтов» и серьезному депремированию.
Если бы показателем эффективности было выбрано «время простоя терминалов в неисправном состоянии», техники мотивировались на минимизацию этого показателя, и жесткость системы мотивации была разумной — стоимость обслуживания сети снизилась бы в 5 раз, при пятикратном же повышении качества ее работы (уменьшении времени простоя в ремонте).
Источник: davtyan.pro
Структурный анализ
Аналитики используют различные инструменты для понимания и описания информационной системы. Одним из способов является использование структурного анализа.
Что такое структурный анализ?
Структурный анализ – это метод разработки, который позволяет аналитику логически понимать систему и ее действия.
Это системный подход, который использует графические инструменты, которые анализируют и уточняют цели существующей системы и разрабатывают новую спецификацию системы, которая может быть легко понятна пользователю.
Он имеет следующие атрибуты –
- Это графический, который указывает на представление приложения.
- Он разделяет процессы так, что дает четкую картину потока системы.
- Логично, а не физически, т. Е. Элементы системы не зависят от поставщика или оборудования.
- Это подход, который работает от обзоров высокого уровня до деталей более низкого уровня.
Это графический, который указывает на представление приложения.
Он разделяет процессы так, что дает четкую картину потока системы.
Логично, а не физически, т. Е. Элементы системы не зависят от поставщика или оборудования.
Это подход, который работает от обзоров высокого уровня до деталей более низкого уровня.
Инструменты структурированного анализа
В ходе структурированного анализа для разработки системы используются различные инструменты и методики. Они –
- Диаграммы потока данных
- Словарь данных
- Деревья решений
- Таблицы решений
- Структурированный английский
- ПСЕВДОКОД
Диаграммы потоков данных (DFD) или пузырьковая диаграмма
Это методика, разработанная Ларри Константином для выражения требований системы в графической форме.
- Он показывает поток данных между различными функциями системы и определяет, как реализована текущая система.
- Это начальная стадия этапа проектирования, которая функционально разделяет спецификации требований до самого низкого уровня детализации.
- Его графическая природа делает его хорошим средством связи между пользователем и аналитиком или аналитиком и разработчиком системы.
- Он дает обзор того, какие данные система обрабатывает, какие преобразования выполняются, какие данные хранятся, какие результаты получены и куда они передаются.
Он показывает поток данных между различными функциями системы и определяет, как реализована текущая система.
Это начальная стадия этапа проектирования, которая функционально разделяет спецификации требований до самого низкого уровня детализации.
Его графическая природа делает его хорошим средством связи между пользователем и аналитиком или аналитиком и разработчиком системы.
Он дает обзор того, какие данные система обрабатывает, какие преобразования выполняются, какие данные хранятся, какие результаты получены и куда они передаются.
Основные элементы DFD
DFD прост для понимания и достаточно эффективен, когда требуемый дизайн не ясен, а пользователю нужен нотационный язык для общения. Однако для получения наиболее точного и полного решения требуется большое количество итераций.
В следующей таблице приведены символы, используемые при разработке DFD, и их значение.
| Площадь |  | Источник или назначение данных |
| Стрела |  | Поток данных |
| Круг |  | Процесс преобразования потока данных |
| Открытый прямоугольник |  | Хранилище данных |
Типы ДФД
DFD бывают двух типов: физические DFD и логические DFD. В следующей таблице перечислены точки, которые отличают физический DFD от логического DFD.
| Это зависит от реализации. Он показывает, какие функции выполняются. | Это не зависит от реализации. Он ориентирован только на обмен данными между процессами. |
| Он предоставляет низкоуровневую информацию об оборудовании, программном обеспечении, файлах и людях. | Он объясняет события систем и данные, необходимые для каждого события. |
| Он показывает, как работает текущая система и как она будет внедрена. | Это показывает, как работает бизнес; не так, как система может быть реализована. |
Контекстная диаграмма
Контекстная диаграмма помогает понять всю систему с помощью одного DFD, который дает обзор системы. Он начинается с упоминания основных процессов с небольшими деталями, а затем переходит к предоставлению более подробной информации о процессах с нисходящим подходом.
Контекстная диаграмма управления беспорядком показана ниже.
Словарь данных
Словарь данных – это структурированное хранилище элементов данных в системе. Он хранит описания всех элементов данных DFD, то есть подробности и определения потоков данных, хранилищ данных, данных, хранящихся в хранилищах данных, и процессов.
Словарь данных улучшает связь между аналитиком и пользователем. Это играет важную роль в создании базы данных. Большинство СУБД имеют словарь данных в качестве стандартной функции. Например, обратитесь к следующей таблице –
| 1 | ISBN | Номер ISBN | 10 |
| 2 | ЗАГЛАВИЕ | заглавие | 60 |
| 3 | SUB | Темы книг | 80 |
| 4 | ИМЯ | Имя автора | 15 |
Деревья решений
Деревья решений – это метод определения сложных отношений путем описания решений и избежания проблем в общении. Дерево решений – это диаграмма, которая показывает альтернативные действия и условия в рамках горизонтального дерева. Таким образом, он показывает, какие условия следует учитывать первым, вторым и т. Д.
Деревья решений отображают взаимосвязь каждого условия и их допустимых действий. Квадратный узел обозначает действие, а кружок – условие. Это заставляет аналитиков учитывать последовательность решений и определяет фактическое решение, которое должно быть принято.
Основным ограничением дерева решений является то, что в нем не хватает информации в своем формате, чтобы описать, какие другие комбинации условий вы можете принять для тестирования. Это единое представление отношений между условиями и действиями.
Например, обратитесь к следующему дереву решений –
Таблицы решений
Таблицы решений – это метод точного описания сложных логических отношений, который легко понять.
- Это полезно в ситуациях, когда возникающие действия зависят от возникновения одной или нескольких комбинаций независимых условий.
- Это матрица, содержащая строку или столбцы для определения проблемы и действий.
Это полезно в ситуациях, когда возникающие действия зависят от возникновения одной или нескольких комбинаций независимых условий.
Это матрица, содержащая строку или столбцы для определения проблемы и действий.
Компоненты таблицы решений
- Заглушка условия – находится в верхнем левом квадранте, где перечислены все проверяемые условия.
- Заглушка действия – находится в нижнем левом квадранте, где описываются все действия, которые необходимо выполнить для достижения такого условия.
- Запись условия – находится в правом верхнем квадранте, где содержатся ответы на вопросы, заданные в квадранте заглушки условия.
- Запись действия – находится в нижнем правом квадранте и указывает на соответствующее действие, полученное в результате ответов на условия в квадранте ввода условия.
Заглушка условия – находится в верхнем левом квадранте, где перечислены все проверяемые условия.
Заглушка действия – находится в нижнем левом квадранте, где описываются все действия, которые необходимо выполнить для достижения такого условия.
Запись условия – находится в правом верхнем квадранте, где содержатся ответы на вопросы, заданные в квадранте заглушки условия.
Запись действия – находится в нижнем правом квадранте и указывает на соответствующее действие, полученное в результате ответов на условия в квадранте ввода условия.
Записи в таблице решений задаются правилами принятия решений, которые определяют отношения между комбинациями условий и направлений действий. В разделе правил
- Y показывает наличие условия.
- N представляет условие, которое не выполняется.
- Пустой – против действия говорится, что его следует игнорировать.
- X (или галочка подойдет) против действий, которые должны быть выполнены.
Например, обратитесь к следующей таблице –
| Авансовый платеж сделан | Y | N | N | N |
| Сумма покупки = 10000 рупий / – | – | Y | Y | N |
| Постоянный клиент | – | Y | N | – |
| АКЦИИ | ||||
| Скидка 5% | Икс | Икс | – | – |
| Не дают скидку | – | – | Икс | Икс |
Структурированный английский
Структура английского языка получена из языка структурированного программирования, который дает более понятное и точное описание процесса. Он основан на процедурной логике, которая использует конструкцию и императивные предложения, предназначенные для выполнения действия для действия.
- Лучше всего его использовать, когда необходимо учитывать последовательности и циклы в программе, а проблема требует последовательности действий с решениями.
- У него нет строгого правила синтаксиса. Он выражает всю логику в терминах последовательных структур решений и итераций.
Лучше всего его использовать, когда необходимо учитывать последовательности и циклы в программе, а проблема требует последовательности действий с решениями.
У него нет строгого правила синтаксиса. Он выражает всю логику в терминах последовательных структур решений и итераций.
Например, посмотрите следующую последовательность действий –
if customer pays advance then Give 5% Discount else if purchase amount >=10,000 then if the customer is a regular customer then Give 5% Discount else No Discount end if else No Discount end if end if
ПСЕВДОКОД
Псевдокод не соответствует ни одному языку программирования и выражает логику на простом английском языке.
- Он может указывать логику физического программирования без фактического кодирования во время и после физического проектирования.
- Он используется в сочетании со структурным программированием.
- Он заменяет блок-схемы программы.
Он может указывать логику физического программирования без фактического кодирования во время и после физического проектирования.
Он используется в сочетании со структурным программированием.
Он заменяет блок-схемы программы.
Рекомендации по выбору подходящих инструментов
Используйте следующие рекомендации для выбора наиболее подходящего инструмента, который соответствует вашим требованиям –
Используйте DFD на высоком или низком уровне анализа для обеспечения хорошей системной документации.
Используйте словарь данных, чтобы упростить структуру для удовлетворения требований системы к данным.
Используйте структурированный английский, если есть много циклов, а действия сложны.
Используйте таблицы решений, когда существует большое количество условий для проверки и логика сложна.
Используйте деревья решений, когда важна последовательность условий и если условий для тестирования мало.
Источник: coderlessons.com
Структурный анализ бизнес-процесса
Бизнес-процесс — это совокупность различных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Эти мероприятия и задачи должны быть взаимосвязаны. [11]
Рассмотрим бизнес-процессы самой ИФНС. На рис. 5 изображена модель «AS-US». ИФНС действует на основании законодательства, управляют сотрудники. ИФНС получает данные о плательщиках, отчетность, входящие и платежные документы, и делает из всего этого отчетность и исходящие документы.
Деятельность ИФНС контролируется законодательством. Всю работу выполняют сотрудники ИФНС.
Рисунок 5. Контекстная диаграмма модели деятельности ИФНС. Модель «как есть»
После описания схемы предприятия проводится функциональная декомпозиция — система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема, при необходимости, разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции основных бизнес-процессов (рис. 6).
Рисунок 6. Диаграмма декомпозиции IDEF0 деятельность ИФНС. Модель (как есть)
По рис 6. видно, что каждый отдел связан друг с другом, во всех отделах работают разные сотрудники, деятельность отделов контролируется законодательством.
Теперь рассмотрим бизнес-процесс одного из отделов ИФНС, например отдел урегулирования задолженности.
Существует добровольное и недобровольное взыскание налога или пошлины с физического или юридического лица.
Все данные по задолженностям хранятся в ИС «Налог».
В ИС «Налог» с исполнительного листа вносятся следующая информация: дата, когда был выдан исполнительный лист; номер дела в Суде; название Суда; в отношении кого заведено дело в Суде; сумма взыскания.
Затем все это направляется в отдел урегулирования задолженности.
На рис. 7 изображена диаграмма IDEF0
Рисунок 7. Диаграмма IDEF0 — Отдел урегулирования задолженностей.
Входными данными системы являются следующие элементы: пароль, логин, дата выдачи исполнительного листа, данные о должнике, номер дела в Суде, название Суда или Судебного участка, сумма взыскания.
Выходными данными являются: сопроводительные письма, внесенные в БД изменения об уплате/неуплате.
На рис. 8. расположена диаграмма декомпозиции модели данной системы.
Рисунок 8. Диаграмма декомпозиции «Отдел урегулирования задолженностей»
Определение уровня доступа и предоставление полномочий происходит от вводимых логина и пароля.
Логин и пароль являются входной информацией, а результатом выполнения является предоставление полномочий. Затем создается сопроводительный лист по решению суда, производится запись в базу данных и вносятся изменения, на выходе получается сопроводительное письмо с измененной базой данных. Все это делают операторы ИС.
Функциональная модель в виде иерархии дерева узлов
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Рассмотрим диаграмму дерева узлов показывающую иерархию работ в модели » AS-IS» (рис. 9).
Рисунок 9. Диаграмма дерево узлов (модель «как есть»
Диаграмма «Деятельность ИФНС» — первый уровень дерева узлов, остальные диаграммы («Деятельность юридического отдела», «Деятельность отдела урегулирования задолженности», «Деятельность информационного отдела» и «Деятельность юридического отдела») — второй уровень дерева узлов.
При построении функциональной модели и модели поток данных, связанной с инициативными туроператорами, были определены «узкие моменты» в существующей системе: малая загруженность персонала, и отсутствие отдела имитационного моделирования. Также было выяснено, что система автоматизированного проектирования сильно нуждается в использовании имитационного моделирования.
Источник: studentopedia.ru
