Стандарт IDEF0 считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, формирующие значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься.
Стандарт IDEF0 представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.
Модель IDEF0 представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня.
На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы. Общее число уровней в модели (включая контекстный) не должно превышать 5-6. Практика показывает, что этого вполне достаточно для построения полной функциональной модели современного предприятия любой отрасли [2].
РЕГЛАМЕНТЫ. Регламентация бизнес-процессов. Я-Агентство. s1e11 18+
Стандарт информационного моделирования IDEF1
Стандарт IDEF1 был разработан как инструмент для анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия. Применение методологии IDEF1 как инструмента построения наглядной модели информационной структуры предприятия по принципу «как должно быть». Пример построения модели показан на рисунке 2.
Рисунок 2 — Пример построения модели IDEF1
Основными составляющими компонентами информационной модели являются:
диаграммы — структурные изображения информационной модели, представляющие, в соответствии с набором правил, состав и логические связи используемых данных;
словарь — значение каждого элемента модели описывается текстовым фрагментом.
Базовым понятием в методологии IDEF1 является понятие сущности. Сущность определяется как реальный или абстрактный объект, набор отличительных свойств которого, называемых атрибутами, известен. Каждая сущность имеет имя и атрибуты [2].
Стандарт динамического моделирования IDEF2
IDEF2 — Simulation Model Design — методология динамического моделирования развития систем.
В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);
Стандарт моделирования процессов IDEF3 — IDEF14
Как спланировать работу по описанию бизнес процессов
Как и в методе IDEF0, основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели — действие, или в терминах IDEF3 «единица работы». Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер.
Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя [2].
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения.
Соединения «и» инициируют выполнение конечных действий. Все действия, присоединенные к сворачивающему соединению «и», должны завершиться, прежде чем начнется выполнение следующего действия. После обнаружения пожара инициируются включение пожарной сигнализации, вызов пожарной охраны, и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены [2].
Соединение «исключающее «или»» означает, что вне зависимости от количества действий, связанных со сворачивающим или разворачивающим соединением, инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением, сможет начаться. Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения. Соединение «исключающее «или»» используется для отображения того факта, что студент не может одновременно быть направлен на лекции по двум разным курсам.
Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно аналитиком. Соединение J2 может активизировать проверку данных чека и/или проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных — при оплате наличными. И то, и другое действие инициируются при частичной оплате, как чеком, так и наличными [2].
IDEF4 — методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы [2]. моделирование бизнес процесс стандарт
IDEF5 — методология исследования сложных систем.
Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику [2].
IDEF6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели [2].
IDEF7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан [2].
IDEF8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции) [2].
IDEF9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение [2].
IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан [2].
IDEF11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан [2].
IDEF12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан [2].
IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан [2].
IDEF14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии [2].
Стандарт моделирования потоков данных DFD
Диаграммы потоков данных DFD представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям — потребителям информации.
Основными компонентами диаграмм потоков данных являются:
системы и подсистемы;
Внешняя сущность обозначается квадратом, расположенным над диаграммой и бросающим на нее тень для того, чтобы можно было выделить этот символ среди других обозначений.
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: «Ввести сведения о налогоплательщиках», «Выдать информацию о текущих расходах», «Проверить поступление денег».
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель данных — это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д.
Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать модели данных.
Построение иерархии диаграмм потоков данных.
Главная цель построения иерархии DFD заключается в том, чтобы сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить его на части с точно определенными отношениями между ними [3].
Источник: studwood.net
Где взять регламенты и стандарты бизнес-процессов компании?
Сегодня я хочу продолжить тему создания стандартов и скриптов.
Речь снова пойдёт о регламентах. Не о формальных регламентах, которые скачивают в интернете, чтобы красиво отчитаться перед руководством. Хочу обсудить реальные документы, которые помогают нашим подчинённым (часто не очень квалифицированным) выполнять сложную работу.
А пока о регламентах продаж — самый востребованный, лаконичный и трудный в создании.
Скрипт общения с клиентом. Чем интересен:
- Очень полезен для неопытных (дешёвых сотрудников), проблема только одна — выучить наизусть и уверенно воспроизводить — опытный тренер дрессирует за 2 часа. То есть — не проблема.
- Трудно создать. Утверждаю обоснованно: буквально вчера один постоянный клиент пожаловался: попытались сделать — запутались.
- Практически всегда умещается на одном листике А4 — просто смешно — почти всегда вызывает у клиентов соблазн сделать самим и почти всегда, потом просят сделать меня.
- Создаётся, тестируется, внедряется быстро. Но только при профессиональном исполнении. Мой рекорд — 3 дня с момента обращения клиента (правда, я был экспертом отрасли). Другой рекорд: разработка набора скриптов, для уникального рынка, уникальной бизнес-модели, очень непростой клиентской базы — 10 стратегических сессий руководителей и внутренних экспертов под моим руководством, продолжительность полтора месяца. Результат — в течение полугода открытие франшизных бизнесов в нескольких крупных городах СНГ.
- Не нужны никакие зажравшиеся «звёзды продаж», можно обойтись дешёвыми, молодыми-покладистыми, они «зазвездят» тоже, но потом, и их можно будет заменить.
Посмотреть примеры одного из моих стандартов продаж и скриптов работы продающего персонала для одного моего постоянного и любимого клиента можно в моем фотоальбоме «Стандарты и бизнес-процессы компании».
Теперь о главном: где взять регламенты и стандарты? Сделать! В сотрудничестве с профессионалом.
Признаки качественного скрипта:
- Лаконичность. Один разговор — один лист. Это не тот случай, когда толщина книги определяет ценность.
- Простота. Реализовать такой скрипт должен любой человек, который умеет читать и помнит как фамилия его мамы — этого достаточно.
- Конкретность. Никакого «бла-бла-бла-бла». Сейчас на рынке таких достаточно, типа: «…опытный бизнес-консультант, возраст 17 лет…», «…преуспевающий бизнесмен, состояние 1млн рублей…», «…известный бизнес-тренер, по образованию воспитатель дошкольного образования…».
- Уникальность. Создан с «0».Под Ваш продукт, Ваш город, Вашу Компанию, Вашего Клиента, Ваше время суток… Никакой универсальности! Это обман!
Посмотреть примеры одного из моих стандартов продаж и скриптов работы продающего персонала для одного моего постоянного и любимого клиента можно в моем фотоальбоме «Стандарты и бизнес-процессы компании».
Если Вам нужны скрипты, обращайтесь!
Источник: vsetreningi.ru
Система стандартизации бизнес-процессов
Можно сформулировать следующее определение системы стандартизации (ее можно так же называть «Система регламентации…») бизнес-процессов: комплекс процессов, методов, инструментов и элементов организационной структуры, обеспечивающий разработку, ввод в действие, контроль исполнения, поддержание в актуальном состоянии и своевременную отмену нормативно-методических документов организации.
Конечно, нормативно-методические документы могут быть совершенно разные. Но основная группа таких документов предназначена для регламентации деятельности, т.е. бизнес-процессов.
Например, у Вас постоянный бардак при заказе или приемке товара, пересорт, другие ошибки, несоблюдение сроков и т.п. Или другой пример: в разных кафе сети, из одних и тех же продуктов, по одной и той же рецептуре получаются разные блюда – клиенты недоумевают (имея в голове «светлый» образ «Макдональдса»). Другой пример. Вы закупили дорогое импортное оборудование, но у вас никто не понимает, когда и каким образом надо выполнять техническое обслуживание, и делают замену запчастей и ТО «на слух», «на глазок» и т.п. Результат – поломки и простой дорого импортного оборудования, закупленного на кредитные деньги.
На рис. 1. представлены важнейшие элементы системы стандартизации бизнес-процессов.
Рис. 1. Элементы системы стандартизации процессов
Среди методов (в рамках системы стандартизации) центральное место занимает Методика моделирования (другими словами – методика описания процессов). Она включает в себя описание подходов к созданию моделей (описаний) процессов организации. Поскольку в настоящее время широко распространены и доступны среды моделирования бизнес-процессов, такая методика должна учитывать возможности и ограничения выбранного программного продукта (MS Visio, Business Studio, Casewise, ARIS и др.).
Говоря простым языком, если уж браться за решение задачи регламентации, то нужно подобрать соответствующий инструмент, который существенно снижает необходимость вступать в длительные и утомительные отношения с кипой разрозненных бумажных документов – разноформатных, написанных коряво, слабо связанных между собой и т.п.
В практике бизнес-моделирования документ, содержащий требования по использованию среды моделирования, часто называют «Соглашение по моделированию». В нашем понимании «Методика моделирования» охватывает больше практических аспектов, чем просто «Соглашение», т.е. может содержать практические требования по более широкому спектру вопросов.
Второй важнейшей методикой является «Методика управления изменениями модели организации». В этом документе представлены требования, которые нужно исполнять при внесении изменений в модель организации. Например, необходимо частично изменить (дополнить) структуру бизнес-процессов, переназначить исполнителей процессов в случае изменения организационной структуры и т.п.
Переводя с «птичьего» языка специалистов по бизнес-моделированию, это означает, что прежде чем использовать систему, надо договориться, как это правильно делать. Нюансы здесь важны. Не получится, как это хотели сделать в одной компании, скопировать руководство по системе моделирования и сделать из него регламент работы собственных сотрудников. Вроде всё понятно, только что именно делать, никто не знает…
Следующий документ – процедура (методика) управления нормативно-методическими документами (НМД) внутреннего происхождения. Документ устанавливает все необходимые требования по управлению жизненным циклом нормативных документов (регламентов, стандартов по бизнес-процессам и проч.), в т.ч.:
• порядок разработка и согласования НМД;
• порядок ввода НМД в действие (в т.ч. кодирование НМД);
• порядок выдачи копий НМД сотрудникам;
• порядок актуализации НМД;
• порядок отмены действия НМД;
Если в организации отсутствует процедура управления НДМ, то база документов, чаще всего, находится в хаотичном состоянии, возникает путаница с версиями, документы теряются и проч.
Эта процедура – способ борьбы с бардаком в части регламентирующей документации. В некоторой компании нами были обнаружены совершенно одинаковые документы, утвержденные под разными названиями. В другой компании, положение об одном из подразделений существовало только в бумажном виде – электронная версия затерялась и т.п.
Далее. Документированные методы контроля исполнения требований стандартов по бизнес-процессам нужны для того, чтобы руководители и сотрудники службы внутреннего аудита могли быстро и эффективно контролировать исполнение требований, сформулированных в регламентах по бизнес-процессам. Одним из возможных является решение, когда методы контроля описаны непосредственно в тексте самих регламентов. В этом случае, проверяющее лицо просто отрывает соответствующий раздел и следует инструкции по выполнению контроля.
Суть состоит в том, что мы определяем контрольные точки внутри процесса, в которых есть смысл проверять исполнение требований. Если сотрудник «напортачил» в этих самых контрольных точках, сразу пойдут «косяки» по дальнейшим операциям процесса. Можно устраивать сверки: вот в этом месте процесса он должен сообщить (отправить документ) туда-то, а пришел ли он получателю?
И если пришел, то когда и т.п. Конечно, сотрудники быстро поймут, где мы их проверяем, и будут делать всё как положено. Но мы ведь этого и добивались! Когда привыкнут правильно работать, поменяем контрольные точки. Только и всего.
Процедура внутреннего аудита содержит требования по организации и проведению аудита. В том числе в ней указано, когда, и каким образом сотрудники отдела внутреннего аудита должны контролировать исполнение требований стандартов по бизнес-процессам.
Так же целесообразно методически проработать систему стимулирования организации в части, ориентированной на создание у сотрудников мотивации исполнять требования регламентов по бизнес-процессам.
Да простят нас специалисты по мотивации персонала, ходят слухи, что некоторые «злые» консультанты по управлению рекомендуют топ-менеджерам компаний «срезать» до 25% оклада руководителей за неисполнение требований стандартов организации. По драконовски? Да, конечно.
Но сколько можно класть на решения руководителей и существующие нормативные документы, подавая пример своим сотрудникам? Пример. В одном сетевом кафе было запрещено курить рядом с черным ходом. Кроме того официанты должны были перед сменой сдавать сотовые в сейф. Реально никто ничего из этого не делал с молчаливого согласия зав. кафе.
Кто виноват, и что делать? Как говорил известный персонаж в фильме «Асса» — «Рыба гниет с головы».
Ещё одним элементом являются методические материалы по обучению сотрудников. Эти материалы могут быть как универсальными, так и создаваться на базе конкретных регламентов по бизнес-процессам.
Для создания системы стандартизации бизнес-процессов могут быть использованы различные программные инструменты. В первую очередь, речь идет о среде бизнес-моделирования (Business Process Architecture), при помощи которой можно описывать:
• подразделения и должности;
• документы и информацию;
Очень важной возможностью современной среды моделирования является возможность формирования регламентирующих документов, таких как: регламенты выполнения процессов (инструкции по выполнению бизнес-процессов), положения о подразделениях, должностные инструкции и проч. Таким образом, в среде моделирования хранится существенная часть информации о деятельности компании. Фактически она является ядром системы стандартизации процессов. Но если ее использовать изолированно, без остальных элементов, представленных на рисунке 2, эффект будет незначительным.
Ситуация, которая, надеюсь, будет становиться всё менее и менее типичной: руководители компании собрались, и решили внедрять процессный подход… В итоге всё свелось к покупке программного обеспечения. Наняли аналитика «ценною подешевле». Потом он в темной, дальней комнате 3 месяца «рисовал» модели процессов… Получилось 2 тома по 100 страниц.
Генеральный подержал у себя на столе этот отчет 3 дня, потом отдал заму, то своему заму и т.д. Через 2 месяца всем стало понятно, что материал нельзя ни к чему приложить. Аналитика уволили, а у Генерального появился устойчивый негативный рефлекс на слова «процессный поход»… Очевидно, что к реальному процессному управлению эта ситуация не имела никакого отношения.
Многие компании, использующие среду бизнес-моделирования, размещают полученные модели процессов на Интранет-сервере. У сотрудников появляется возможность просматривать схемы процессов, переходя по гиперссылкам с уровня на уровень, и от процесса к процессу. Это является весьма удобным для быстрого поиска нужной регламентирующей информации и понимания бизнес-процессов организации в целом.
Выгруженные из среды бизнес-моделирования проекты нормативных документов необходимо «прогнать» по процедуре согласования, утверждения и ввода в действие. Далее оригиналы этих документов нужно хранить. С этим тоже должен быть порядок. Можно, конечно, хранить документы в виде файлов на сервере или специально разработанном для этих целей электронном архиве компании.
Но более эффективным решением будет использование современной системы электронного документооборота. Тем более, что в такую систему можно осуществлять экспорт нормативных документов прямо из среды моделирования.
Короче, если у вас есть деньги, установите систему электронного документооборота. Это так же поможет избавиться от бардака, потери документов и т.п.
Самые хорошие методики и программные продукты бесполезны, если не отлажены реальные процессы, которые их используют. Поэтому при внедрении системы стандартизации процессов, наряду с разработкой методик и настройкой инструментов необходимо «запускать» и отлаживать соответствующие бизнес-процессы. К ним относятся:
• управление системой стандартизации процессов;
• контроль исполнения процессов;
• управление жизненным циклом НМД;
• обучение персонала (в части ввода в действие новых регламентов по процессам);
• стимулирование персонала (в части создания культуры работы по стандартам);
В зависимости от подхода, участниками данных процессов могут быть сотрудники различных подразделений организации, в т.ч. отдела организационного развития, менеджмента качества, внутреннего аудита и т.п. Обязательными участниками процессов описания и регламентации должны стать руководители и специалисты подразделений организации.
Источник: stydopedia.ru
