В одной из статей раздела «Мифов управленческого консалтинга» я писал о том, как не нужно регламентировать бизнес-процессы в 21 веке. Давайте теперь разберемся, как нужно разрабатывать регламенты бизнес-процессов при их внедрении средствами ИТ.
Прежде всего, отметим, что регламенты бизнес-процессов нужно разрабатывать для понимания схем человеком, а не для проектирования бизнес-процессов в специализированном программном обеспечении. Для этих программ описание бизнес-процессов делается на их языке, а не в текстовом виде.
Не будем долго останавливаться на разделе «Общие положения». Если вы не хотите путаницы, не забудьте при разработке регламента бизнес-процесса указать его название, статус (в работе, утверждён и т.д.), дату изменения статуса, ответственного и другие параметры, принятые в системе электронного документооборота.
Об ИНСТРУКЦИИ по написанию РЕГЛАМЕНТА бизнес-процессов компании. О публикации курса по РЕГЛАМЕНТАЦИИ
А вот все остальные данные, которые нужно указать в регламенте бизнес-процесса при его разработке, зависят от нотации (набора правил), в которой выполнена графическая схема бизнес-процесса. Примеры бизнес-процессов, разработанных в разных нотациях, можно посмотреть по приведённой ссылке.
Например, в классическом варианте функциональной нотации IDEF0 на схеме отображены только имя функции, входы, выходы, управление, механизмы (включая модификацию — «вызов»). Предполагается, что другие параметры бизнес-процесса в этой нотации (владелец, участники, показатели), указываются в сопроводительных текстах или, другими словами, регламентах. Но мы в своей работе используем расширенную нотацию IDEF0, в которой эти параметры присутствуют на графической схеме, поэтому указывать их при разработке регламента совсем не обязательно.
Другой пример. В нотации IDEF0 и некоторых других, источник или потребитель граничных стрелок (то есть стрелок, указывающих на связь с другой диаграммой) не указывается. То есть функцию, с которой связана граничная стрелка, можно определить, только изучив другую диаграмму. Тогда для понимания человеком при разработке регламента бизнес-процесса нужно указать эту функцию. С другой стороны, в нотации BPMN можно указать внешнюю ссылку граничной стрелки на схеме и включать её в регламент не обязательно.
Если вам доводилось рисовать графические схемы реальных бизнес-процессов, вы сталкивались с тем, что отобразить все связи между объектами стрелками проблематично. Дело в том, что связей этих на диаграмме могут быть десятки и даже сотни, а такое количество стрелок делает схему не читаемой. Поэтому в программах, предназначенных для рисования графических схем бизнес-процессов, существует специальный механизм привязки множества объектов к одной стрелке. То есть на схеме разработчик отображает одну стрелку, например, «Пакет документации» и привязывает к этой стрелке все документы, входящие в пакет.
Лекция 5: Регламентация и бизнес-процессы
При использовании этого механизма, все объекты на схеме не видны, и для демонстрации их человеку необходимо указать список объектов в регламенте. Это ещё один вид информации, без которого не обойтись при разработке регламентов бизнес-процессов.
Таким образом, для понимания бизнес-процессов человеком регламенты необходимы. Но перечень информации, включаемой в регламенты, зависит от нотации описания схемы бизнес-процесс, и не имеет ничего общего с составом регламентов, которые разрабатывались в прошлом веке.
По следующей ссылке можно посмотреть некоторые примеры разработанных нами описаний бизнес-процессов. На сайте также размещена процедура заказа работы по совершенствованию бизнес-процессов. В разделе «Стоимость описания бизнес-процессов» мы рассказываем, как сэкономить при заказе этой услуги.
Если вы заполните эту форму, мы подготовим коммерческое предложение, оптимизирующее ваши расходы на выполнение этой работы.
Как заказать наши услуги
УЗНАТЬ ПОДРОБНЕЕ
- Наши услуги
- Сколько стоит консалтинг?
- Примеры работ
- Отзывы клиентов
- Подписка на рассылку
Источник: piter-consult.ru
Регламентация бизнес-процессов, универсальные требования к регламентам — презентация
Регламентация бизнес-процессов предполагает описание процессов взаимодействия разных сотрудников предприятия. Важно отличать регламентацию бизнес-процессов от инструкции, которая касается в большинстве случаев только одного конкретного исполнителя. То есть, всё множество инструкций по выполнению конкретных работ для каждого пользователя представляют собой один массив данных. В свою очередь, регламентации составляются по каждому бизнес-процессу и описывают порядок взаимодействия всех включённых в конкретный бизнес-процесс пользователей, при этом каждый процесс составляет отдельный массив данных. Регламентация бизнес-процессов является необходимым этапом для того, чтобы затем провести цифровую трансформацию бизнеса с использованием BPMS или иных систем. Регламентация бизнес-процессов
Изображение слайда
Слайд 3: Цель регламентации бизнес-процессов
В большинстве случаев регламентация преследует следующие цели: Поиск и устранение «узких мест» бизнеса, которые могут являться причиной перерасхода ресурсов организации – времени, финансов. Стандартизация бизнес-процессов, выработка определённых шаблонов для каждого из них. Накопление опыта и знаний.
Когда конкретный регламент отсутствует, всё происходит стихийно, и накопление базы знаний невозможно. Полноценный и качественный контроль за прохождением бизнес-процессов на всех этапах. Уменьшение количества ошибок в работе, сокращение времени на обработку запросов, повышение мотивации сотрудников. Внутренний аудит.
Изображение слайда
Слайд 4
В целом можно говорить о том, что если регламентация бизнес-процессов не проведена, если все принципы работы находятся в головах сотрудников, то отсутствует и чёткое понимание того, почему нужно придерживаться сложившихся правил, и возможность контроля. Очень сильно возрастает роль человеческого фактора. Второй крупный недостаток – невозможность внесения улучшений.
Пока не проведена регламентация, недостатки существующего принципа работы тоже не видны. А если вносить изменения, то трудно понять, к каким результатам они реально приводят. Поэтому регламентация бизнес-процессов совершенно необходима для любого бизнеса.
Изображение слайда
Слайд 5: Как проводится регламентация бизнес-процессов
Чтобы регламентация бизнес-процессов была выполнена правильно, потребуется определить для каждого из процессов несколько параметров. Владелец процесса (лицо, которое им управляет). Входы и выходы процесса («вход» – событие, инициирующее бизнес-процесс, «выход» – событие, завершающее его). Участники бизнес-процесса. Используемые технологии и ресурсы.
Перед тем, как проводить регламентацию, крайне важно отделить данный бизнес-процесс от всех других, чтобы избежать любых дублей, например, дублирования полномочий разных сотрудников. За каждый бизнес и процесс и за каждый его этап должен отвечать только один человек.
Изображение слайда
Слайд 6: Требования к регламенту бизнес-процесса
Структура бизнес-процесса, нарезка процедур Процесс должен быть описан в хронологическом порядке процесса, а не дня/месяца. Если действие совершается 2-го числа месяца, но в конце процесса – это действие должно быть в конце регламента, а не в начале. Вход – это что предшествует, запускает процесс или процедуру. Вход не пишется в качестве первой операции, он уже произошел раньше.
Вход – это событие, или результат других процессов, или дата. И наоборот – первая операция не может быть входом, так как она не произойдет сама по себе. Сначала пишутся процедуры, которые происходят всегда (основные), а после них пишутся те, которые бывают иногда. Все процедуры, которые происходят параллельно, пишутся рядом.
Если процесс разветвленный, то структуру процедур лучше нарисовать графически. Если линейный, то необязательно. Деление на процедуры условно и делается для того, чтобы описать процесс минимумом операций и избежать повтора одинаковых частей в разных процедурах. Процедура, как правило, вся укладывается в один временной цикл, например, еженедельно или ежемесячно.
Вкрапление туда действий с другим циклом, как правило, означает, что надо выделить эти действия в отдельную процедуру или прикрепить к другой. Графическую структуру процедуры рисуем, если она НЕ линейная. Если линейная, то не надо.
Изображение слайда
Слайд 7: Отсылки и наименования
Одно и то же правило/требование/процедура не может писаться в разных регламентах. В таких случаях надо делать ссылку. Иначе получится, что в одном месте поменяем, а в другом — оставим по-старому и будут действовать одновременно две противоречащие друг другу нормы. Ссылка включает И номер И название процедуры. Ссылки на приложения.
Каждому документу надо дать имя и ссылаться на имя, а не на номер, так как нумерация приложений может меняться, и человек никогда не запомнит их. Если документ относится к двум регламентам – в одном из них надо делать ссылку. Называть документ/подразделение надо везде одинаково, для чего и есть общий глоссарий.
Изображение слайда
Слайд 8: Контрольные точки
Контрольная точка – это момент, когда проверяется состояние процесса. То есть это такая же ОПЕРАЦИЯ, но результат которой кто-то проверяет. Требование : Должен быть предусмотрен способ, как будет обнаружено невыполнение КТ. За КТ есть ответственный (кто будет виноват в ее нарушении). Нет смысла в контроле, если нет ответственного лица.
Там, где нужны копии контролеру бизнес-процессов, это должно быть указано. КТ в разных процедурах должны быть с РАЗНЫМИ номерами. Сквозная нумерация уменьшает путаницу для читателей.
Изображение слайда
Слайд 9: Задачи владельца процесса регламента. Содержание регламента
Требование : Согласование с руководителями их подразделений. Каждый имеет право давать замечания по своим ячейкам. Учесть возможные проблемы, отклонения от прямого пути. Разработка критериев и требований. Иногда работа над регламентом выводит на более глубокие нерешенные проблемы, которые нельзя решить в рамках регламента и ограниченного времени.
Эти проблемы надо хотя бы обозначить и сформировать по ним задачу с конкретным сроком решения, в этом случае можно в регламенте умолчать или «сделать заплатку». Не добавлять ненужную работу другим подразделениям, искать более рациональные решения, в том числе с привлечением к поиску решений других участников процесса.
Источник: slide-share.ru
Регламентация процессов — регламенты и инструкции
Как добиться устойчивости работы Вашего предприятия, как быть уверенным в том, что поставленная задача будет выполнена вовремя и с надлежащим качеством. Руководить каждым сотрудником – никаких сил не хватит. Ставить своих людей – насколько долго они останутся своими. Нужна регламентация процессов — требуется регламентировать действия сотрудников не своими личными указаниями, а регламентами и должностными/ операционными инструкциями подробно описывающими, предписанные им для выполнения действия.
Регламентация процессов — плюсы и минусы
В данном случае, сотрудник получает инструкцию для работы, работая в соответствие с которой он будет уверен, что поступает правильно, а руководитель получит надежду, что инструкция будет исполняться и нет необходимости в постоянном личном контроле. Конечно, у данного подхода есть противники, которые скажут, что это убивает свободу решений в Компании. Им можно возразить, что необходимую долю свободы можно внести в документы, а абсолютная свобода сотрудников вредна для Компании, поскольку внутри нее появляется фактор возмущения, который может помешать выполнению работ.
Поэтому будем считать, регламентация процессов предприятия необходима и пойдем далее. Что нам нужно, чтобы создать инструкции и регламенты? Нам необходимо подробно описать действия каждого сотрудника в различных ситуациях. Фактически мы должны описать последовательность действий сотрудников всего предприятия от поставщика до клиента.
Прочитать про то, как создать идельный регламент можно тут.
Если мы возьмем определение бизнес процесса, то станет ясно, что наша задача лежит в области описания бизнес-процессов. Теперь стало понятно, почему сейчас столь большое внимание уделяется бизнес-процессам, их описанию, и инжинирингу. При достаточно насыщенных рынках сбыта Компании ищут повышения прибыльности внутри себя, разбираясь в работе своих подразделений, своих бизнес-процессах.
Регламентация процессов — понимание «как есть»
Но прежде чем говорить о перестройке деятельности предприятия необходимо понять текущую ситуацию и на основе ее оценки браться за сложное дело перестройки внутренних бизнес-процессов. Иначе мы можем устроить революцию, которая, как правило, ничем хорошим не заканчивается. В настоящее время большинство Компаний проводят работу по описанию бизнес-процессов с помощью различных графических средств.
Использование графических средств описания обусловлено удобством и строгостью получаемого описания, поскольку в отличие от текстового описания модель отражает логику выполнения действий намного лучше и нагляднее. Если в текстовом описании все зависит от человека создающего описание, то при описании в графическом виде, используя некие стандарты моделирования, результат описания будет являться более понятным.
Регламентация процесса — не только модель
Но многие забывают о том, что модель бизнес-процесса – это еще не конечный результат описания бизнес-процесса, что нам необходимо еще множество документов, которые требуются для выполнения бизнес-процесса (различные регламенты, штатные расписания, должностные инструкции, положения о подразделениях, Технические задания на внедрение ИС и т.д.). Перед нами встает задача получать текстовые документы, поскольку обучение сотрудников всего предприятия пониманию графической формы представления может отнять много ресурсов, да и текстовый документ все еще является более привычным для основной массы сотрудников.
В тоже время клиентские места средств описания бизнес-процессов, с помощью которых можно работать с графическими описаниями устанавливать на компьютеры всех сотрудников дорого и не нужно. Но конечно подразделения ИТ, инжиниринга, развития и т.д., безусловно, должны иметь данные средства для своей работы.
Вернемся к нашей проблеме. Мы нарисовали графическое описание бизнес-процесса и теперь на его основе необходимо создать текстовое описание процесса. Можно взять модель и вручную, смотря на нее, составить описание бизнес-процесса (например, регламент). Что мы получаем в данном случае – двойной труд по описанию процесса.
Формирование регламента на основе модели
Что нам нужно? Сформировать описание процесса на основе модели автоматически. Если у нас есть такая возможность, то достаточно нарисовать модель бизнес-процесса, и мы сможем автоматически получить текстовое описание процесса. Эта возможность является обязательным требованием к средству описания бизнес-процессов.
Фактически необходимо иметь возможность, с помощью некого простого языка программирования, написать программу, которая будет выводить текстовое описание на основании нарисованных моделей. Это требование удовлетворяется только в достаточно сильных средах по описанию бизнес-процессов.
Представим, что мы работаем с такой средой, тогда мы можем написать программу (конечно с помощью программистов) и далее, запуская данную программу, мы имеем средство документирования моделей в текстовой форме, применяя которое к разным моделям мы будем получать текстовое описание моделей автоматически. Попробуем усложнить нашу задачу – теперь нам нужно не просто описание модели в текстовой форме, а актуальная должностная инструкция. Для выполнения данной задачи необходимо анализировать не только одну модель, а проводить анализ всей совокупности взаимосвязанных моделей. А для этого необходимо, чтобы методология моделирования позволяла связывать между собой модели описывающие разные предметные области (например, бизнес-процессы и организационную структуру).
Регламентация процессов и операционные/должностные инструкции
Это достигается путем размещением одного объекта на нескольких моделях, т.е. исполнитель функции, присутствующий в модели бизнес-процесса присутствует в организационной диаграмме. Что нам дает данный подход – все просто, используя данные связи между моделями и имея язык программирования позволяющий анализировать данные связи, мы получим возможность сбора и анализа информации со всей базы моделей, что позволяет нам делать отчеты, основанные на данных с разных моделей. Например, выбираем должность, смотрим, в каких бизнес-процессах она участвует, какие функции выполняет, с какими документами работает, далее мы можем рассмотреть какими знаниями должен обладать сотрудник для замещения выбранной должности и т.д. Все эти собранные данные мы размещаем в документе, с учетом нужного нам формата и получаем на выходе программы отчет ” Должностную инструкцию”. Причем если у нас что-то поменялось в процессе, то для получения актуальной должностной инструкции нам необходимо только запустить программу формирования отчета и получить на выходе актуализированную должностную инструкцию.
Это очень удобно, если на предприятии часто меняются процессы, оргструктура, то мы просто отражаем изменение ситуации, исправляя модели и потом сразу получаем полный комплект актуальных документов.
Регламентация процессов — чудес нет
Регламентация процессов на основании моделей — это не волшебная палочка – мы можем получить из среды моделирования только те данные, которые там расположены, т.е. размещены на моделях. Как правило средство моделирования обладающее возможностями формирования отчетности на основе моделей позволяют производить описание различных предметных областей деятельности предприятия и всегда есть возможность заложить в модели любые данные, которые нам могут понадобиться. Если говорить о предметных областях, то это процессы, организационная структура, информационные системы, знания, полномочия, данные, продукты/услуги, цели и т.д.
Но это еще не все – простая генерация отчетов даже со сложными алгоритмами – это конечно очень упрощает работу, а вот сбор материалов для анализа и первичный анализ бизнес-процессов с помощью программных средств – это следующая задача над которой сейчас ведутся работы в настоящее время. Проверки правильности нарисованных моделей по заранее сформулированным правилам, анализ организационных и информационных разрывов в процессах и решение других задач с помощью программных средств – это то, что может помочь при инжиниринге бизнес-процессов и облегчить эту сложную задачу.
Источник: koptelov.info