В предыдущем номере «ДО» мы отметили актуальность и значение бизнес-процессов в компании. Теперь определим, по каким принципам проводить их анализ, как правильно использовать полученную информацию и выявить проблемы.
При процессном подходе ведения бизнеса, когда основной упор делается на правильное выполнение последовательности действий, главным объектом изучения как раз и являются текущие процессы.
Прежде чем оптимизировать, необходимо их тщательно изучить. Основной метод исследований — это описание процесса на основе непосредственного общения с его участниками. В первую очередь, определите, кто является хозяином процесса (это руководитель того подразделения, где сосредоточен основной функционал деятельности).
Для любой торговой организации характерна приемка товара от поставщика и его оприходование. Например, в нашей компании в этом принимают участие сотрудники сразу двух подразделений: отдела закупок и отдела логистики. Организационно они подчиняются разным руководителям, и определить хозяина процесса зачастую бывает затруднительно.
В этом случае перераспределением ответственности должен заняться тот, кому подчиняются оба начальника участвующих в процессе структурных подразделений. В нашем случае это руководитель управления запасных частей. А чтобы избежать разного понимания сути процесса и размывания границ ответственности, обсуждение деталей процесса лучше вести в присутствии этих менеджеров среднего и высшего звеньев.
Перед описанием любого про-цесса определимся с его параметрами:
1. Цель — для чего необходимо четко отлаженное его функционирование.
2. Участники — конкретные исполнители, чьи обязанности создают его основной функционал:
* функции, которые они выполняют;
* принципы их взаимодействия между собой;
* данные, передаваемые ими друг другу.
Обладая этой информацией, приступаем к непосредственному опросу участников. Он проводится в различных формах: письменно или устно, в виде закрытых и открытых вопросов, требующих соответственно однозначного или развернутого ответа. Выбор способа зависит как от личности специалиста, так и от опрашиваемых участников процесса.
Самым важным на данном этапе является способность того, кто проводит опрос, найти контакт с опрашиваемыми, «разговорить» их. Некоторые участники стремятся сознательно утаить ряд специфических особенностей выполняемых ими функций. Причины тому самые разные.
Например, сотрудник не хочет, чтобы стал известным тот факт, что на выполнение определенного действия он тратит намного меньше времени, чем предполагается его руководством. Или просто он не хочет вносить ясность в выполняемый им функционал, опасаясь, что таковые навыки приобретет кто-то другой. Нередко человек стремится убедить всех в своей исключительности, внушить мысль, что без него ничего не будет работать.
В такой ситуации самый действенный способ убеждения сотрудника — это объяснение, что цель описания процесса, участником которого он является, — только регламентация выполняемых им функций. В результате этого не будут усложнены или значительно видоизменены его «исключительные» функциональные обязанности.
Какой формат выбрать?
Полная информация от всех участников бизнес-процесса позволяет приступить непосредственно к моделированию его схемы. В настоящее время существует множество форматов для описания таких моделей. Каждый из них имеет свою специфику и наилучшим образом подходит для описания конкретного вида бизнес-процесса.
При выборе формата нужно иметь в виду одно обстоятельство: результатом описания должна стать модель процесса, понятная как любому из его участников, так и начальнику подразделения и руководству компании. На начальном этапе следует выбрать тот формат, который позволит описать существующее положение дел в привязке к имеющейся в компании организационной структуре. Такой подход объясняется тем, что на практике понять процесс абстрактно, в отрыве от оргструктуры, бывает затруднительно.
В определенной степени оптимальным считается формат WFD (Work Flow Diagram — Диаграмма потоков работ), когда выполняемые работы привязываются к конкретным сотрудникам, встроенным в организационную структуру компании на описываемом этапе. Можно использовать и различные специализированные программные продукты.
Однако такие специальные оболочки, как правило, дорого стоят, и для работы с ними потребуются определенные знания и опыт. Более простой вариант — применение стандартной графической программы. Например, в нашей компании используется Microsoft Office Visio, которая насчитывает значительное число стандартных шаблонов по самым различным разделам: бизнес, расписания, блок-схемы и т.п. При помощи имеющихся в программе инструментов можно описать практически любую схему.
В привязке к существующей оргструктуре удобнее всего использовать так называемую функциональную блок-схему, в которой показываются потоки работ, выполняемых конкретными исполнителями. В ней по горизонтали или по вертикали располагаются столб-цы, соответствующие конкретным должностям, а в теле таблицы при помощи условных обозначений показаны работы, выполняемые ими. Под условными обозначениями понимаются стандартные фигуры, имеющиеся в программе для описания простой блок-схемы: процесс, решение, данные и т.д. WFD позволяет описать бизнес-процесс как совокупность всех составляющих его работ.
Очень удобно, если на схему потоков работ наложить схему потоков данных, которые передаются между исполнителями при выполнении ими своих функциональных обязанностей. Послед-нее описывается так называемым форматом DFD (Data Flow Diagram — Диаграмма потоков данных). Совместное использование WFD и DFD дает очень наглядную картину процесса. А в привязке к организационной структуре получается достаточно исчерпывающая картина процесса в модели «как есть».
Основная опасность, которая подстерегает специалиста при описании процесса, — это соблазн при обнаружении какой-либо нелогичности сразу же оптимизировать этот момент. То есть перейти к модели «как надо». Могут быть ситуации, когда непонятно, кто выполняет и кто ответственен за определенные этапы процесса.
В этом случае на стадии описания модели «как есть» лучше в столбце с наименованием должности указывать не одну, а сразу несколько через запятую. Тогда на этапе оптимизации процесса будет легче определиться с тем, кому в реальности выполнять соответствующие функции. В любом случае, при описании модели «как есть» нельзя оптимизировать процесс. Это уже модель «как надо».
Подробнее об этом читайте в следующем номере «ДО».
директор по коммерческому развитию компании «Авторай»
помощник директора по коммерческому развитию компании «Авторай»
Источник: ulpressa.ru
Описание бизнес-процессов: как избежать ошибок
Первым этапом построения информационной системы на предприятии обычно является описание его бизнес-процессов. Однако специфика российского рынка такова, что из-за ошибок, совершенных на этой стадии, выполненные работы зачастую оказываются бесполезными.
Определиться с целями
Внедрение информационных систем (ИС) среднего и крупного класса сопровождается, как правило, описанием бизнес-процессов (БП) предприятий-заказчиков. Чаще всего подобная документация составляется на этапе предварительного обследования, позволяющего определить, насколько успешно БП организации можно перенести в рамки предлагаемой ИС.
Такую цель обычно подразумевают ИТ-консультанты, однако руководство организаций, внедряющих ИС, неизменно видит вопрос несколько шире. Хотя этап описания БП почти всегда присутствует в плане работ по проекту, его результаты оцениваются крайне неоднозначно. Основной причиной этого является ряд ошибок, которые зачастую делают как заказчики, так и исполнители.
Уже при принятии решения об инициации описания БП обычно и совершается наиболее распространенная ошибка – недостаточно четко формулируются цели подобного исследования, что ведет к дальнейшему непониманию между заказчиком и исполнителем. Внедрение дорогостоящих систем среднего и крупного класса для предприятия не является самоцелью.
Заказчик зачастую считает, что использование таких систем, помимо чисто технических аспектов, послужит отправной точкой для определенной перестройки части работ на предприятии. Эти ожидания редко формулируются в какие-либо конкретные требования, обычно ИТ-консультантам приходится иметь дело с более-менее абстрактными пожеланиями, такими как: «отдел Х работает неэффективно, надеюсь, ваша система наведет там порядок», «хочется, чтобы мы работали как передовые компании в отрасли, например, как фирма Y». Причем даже такие пожелания зачастую теряются либо изменяются до неузнаваемости, пока доходят до рядовых исполнителей. Чтобы избежать последующих ошибок, эксперты рекомендуют составлять задание на описание БП не менее серьезно и подробно, чем ТЗ на программный комплекс.
«Как есть» и «как должно быть»
В зависимости от целей, которые ставит перед внедрением ИС руководство предприятия, при описании бизнес-процессов «как есть» (as is) необходимо уточнять требуемый «разрез» и детализацию. Причем подобные требования могут различаться для разных департаментов.
Например, если в новой системе планируется организовать работу отдела снабжения таким образом, чтобы минимизировать вероятность сговора между менеджерами отдела и поставщиками, то при описании процессов «как есть» целесообразно уделить особое внимание существующим принципам выбора поставщиков. Если для отдельного департамента планируется ввести систему ключевых показателей результативности, то имеет смысл «заказать» при описании БП учет количественных показателей работы. При отсутствии же подобных требований наверняка получится описание БП структурных подразделений, сделанное по единой схеме. Поэтому, если заказчик рассчитывает на получение результата в определенных, интересующих его разрезах, ему следует заранее сформулировать их.
 Подобных «рекомендаций» при описании БП стоит опасаться |
Многие ИТ-консультанты включают в план работ по проекту пункт «Описание бизнес-процессов «как должно быть» (to be)». На практике полноценную работу по этому пункту могут выполнить не так много компаний, действующих на российском рынке.
Как правило, это наиболее крупные фирмы, имеющие опыт построения БП как западных компаний, так и передовых отечественных, и умеющие разумно применять данный опыт к конкретному российскому предприятию с учетом отраслевой и прочей специфики. Наряду с успешными примерами, в России налицо совершенно явная тенденция – многие ИТ-консультанты не слишком четко представляют, как подступиться к описанию БП «как должно быть».
Для них, если описание «как есть» показало, что процессы в целом ложатся в структуру предлагаемой ИС, этот этап работ считается законченным, и они стремятся как можно быстрее начать внедрение. В результате заказчик рискует в качестве результата описания процессов «как должно быть» получить набор диаграмм существующих БП с «ценными рекомендациями» перенести их в предлагаемую ИС. Справедливости ради стоит сказать, что описание процессов «как должно быть» действительно является сложной задачей. Если заказчик не предъявляет четких требования по данному блоку, ИТ-консультанту трудно понять, чего в действительности от него хотят и в каком направлении следует двигаться. Задать такой вектор, безусловно, необходимо самому заказчику, поскольку лучше него конкретный бизнес никто не знает.
Источник: studfile.net
Описание бизнес-процесса «как есть»
Мы предлагаем описание бизнес-процесса «как есть». Когда это нужно?
1. Когда у вас все хорошо работает — результат надо закрепить, чтобы сохранить этот опыт в компании;
2. Чтобы узнать, хорош ли ваш процесс, что можно в нем улучшить — первый шаг на пути к оптимизации;
3. Чтобы навести порядок и выстроить процессы «как надо».
Создание схем бизнес-процессов:
• Описание в любой нотации (BPMN 2.0, Workflow, IDEF, ePC и др.)
• Или в индивидуальной нотации
• В 1 схему или разбивка на уровни и подробное описание
• Анализ, выявление точек роста и рекомендации
• Подготовка к автоматизации, создание ТЗ
• Подбор вариантов автоматизации
Разработка регламента бизнес-процесса:
• По стандарту ISO
• Или по нашему улучшенному стандарту, удобному для людей
Настройка правильного управления бизнес-процессами:
• Оцифровка целей и показателей процесса
• Автоматизация отчета по процессу
• Автоматизация контроля исполнения процесса
Мы можем описать процесс разными способами:
- регламент (мы разработали хорошую форму, удобную для понимания людьми)
- только схемы (в различных нотациях: BPMN 2.0, ePC, IDEF, WorkFlow и др.)
- техническое задание на программу
- специально разработанный формат
Глубина описания процессов зависит от ваших целей и необходимости: мы можем описать как структуру процессов, их входы-выходы, взаимодействие и распределение ответственности на верхних уровнях, так и расписать всё подробно, до уровня рядовых специалистов.
Среди сопутствующих услуг у нас есть и очень подробное описание операций: стандартизация, хронометраж, посекундная оптимизация.
— Более 120 регламентированных бизнес-процессов
— Более 30 оптимизированных бизнес-процессов с внедрением
Пример описания бизнес-процесса в в виде схемы в нотации BPMN 2.0 (описана 1 процедура)
Пример описания бизнес-процесса в виде регламента (схемы + необходимые пояснения), нотация Workflow
Описание может быть в любой нотации (BPMN 2.0, Workflow, IDEF, ePC и др.)
Модели бизнес-процессов в соответствии с любыми существующими стандартами (включая ГОСТ ISO)
Что нужно от Вас:
- заполнение анкет сотрудниками
- предоставить нам возможность обследования процесса (проведение интервью по согласованному графику, демонстрация процесса)
- своевременно давать ответы на вопросы
- предоставить образцы документов, которые используются в процессе (можно с воображаемыми данными)
- определить ответственного за проект с Вашей стороны с правом принятия решений
- определить владельца процесса (поможем, если есть трудности)
- владелец процесса должен прочитать регламент и дать свои замечания (рекомендуем также разослать проект регламента всем участникам и направить нам их замечания или вопросы)
0 0 0 0 722
Вы сотрудничали с этим исполнителем? Оставьте отзыв о его работе
Источник: hrtime.ru
