Построение и анализ модели как есть

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

Модель функциональная — это система связанных систем: помимо запланированного, многие структурные элементы, процессы и функции возникают в том числе как результат ошибок в управлении, непонимания сотрудником поставленной задачи или необъективной оценки достигнутого результата руководителем. Неадекватный анализ внешних воздействий, дублирование задач, многообразие решений, психология принятия решений и многие другие обстоятельства являются основаниями для исследования, которое анализирует модели управления организацией и предлагает эффективные решения.

В любой момент времени можно определить, как выглядит модель функциональная организации в состоянии «как есть» (AS IS). С позиций сложившихся методик можно выполнить анализ полученных представлений и сформулировать пути более эффективной работы и дальнейшего развития организации.

Основная методика моделирования IDEF0 (Integrated Definition Function Modeling) в настоящее время представлена различными вариантами и реальным положительным опытом. В его основе лежит представление о неделимой частице – блоке, который отображает некоторую бизнес-функцию. Стороны блока – его роли. Левая – вход, правая — выход, верхняя – управление, нижняя — механизм.

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

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

Результат применения методики: «как будет» (TO BE) обычно представляет, как внедряется та или иная информационная система, а процесс развития компании рассматривается как переход из сложившегося состояния в заданное. Само по себе применение методики не всегда дает существенный результат. Далеко не каждая функциональная модель управления может быть адаптирована к той или иной современной информационной системе.

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

При этом предположении можно определить, как выглядит модель функциональная для данной организации в положении «как есть» (AS IS) в чистом виде. Если впоследствии окажется, что материальная составляющая показала себя не с лучшей стороны, потребуется другое моделирование.

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

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

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

Понимать модели управления организацией очень важно.

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

Не суть важно, кто выполняет построение модели. Это может быть сторонняя организация или собственное подразделение. Существенно разграничение: управление организацией – это одно, моделирование – это совершенно другое.

Для точного определения состояния «как есть» не следует ориентироваться на мнение сотрудников – в данном случае персонал по всем его позициям есть прежде всего предмет исследования. Их описывает функциональная модель процесса, в конечном итоге дающая полную картину всех процессов.

Влияние руководства и собственников существенно замедляет процесс моделирования, что ухудшает функционирование организации. Об этом говорит опыт применения методики. Построение модели «как есть» в контексте понимания ее руководством носит специфический личный характер.

Выбрав исполнителя, следует принять как безусловный факт: именно он несет ответственность за свои действия и не обязан выполнять советы, рекомендации или прямые указания со стороны организации.

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

Взяв любую существующую систему (например, «1С: Бухгалтерия», «1С: Документооборот», eDocLib), можно не только видеть уровень представлений разработчика о ее функционале, но и сразу столкнуться с ограничениями в реализации определенных бизнес-функций.

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

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

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

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

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

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

В последнее время появились и получили свое развитие инструментальные средства для создания и обработки электронных таблиц и документов при помощи библиотек PhpOffice (PhpExcel и PhpWord). Использование этих средств позволяет вычленять из реальных документов только нужную информацию и формировать нужные результаты, которые можно открывать традиционно в MS Excel и MS Word.

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

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

В частности современная электронная таблица — это прежде всего нужный функционал, а реальное ее содержимое — актуальное отражение того или иного функционального блока на структурной модели. Если в качестве примера взять «1С: Бухгалтерию», то можно заметить, что ее структура и функциональность полноценно отражают действительность. При этом техническая поддержка производителя нивелирует жесткость системы, предоставляя возможность потребителю получать нужный функционал, отражающий изменения в информационном бизнес-пространстве.

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

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

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

Идеальная организация — такая, которая, по сути, «не существует», но функция ее выполняется. Когда организация органично вписывается в окружающую ее социально-экономическую среду, становится ее незаменимой частью и адекватно развивается, только тогда эта среда обеспечит жизнь компании и будет заботиться о ней, как о части своего организма.

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

Любая программа (так свидетельствует опыт) может быть улучшена, поскольку сама по себе решена. Это дает основание пересмотреть алгоритм решения, его результат и более компетентно оценить входные данные.

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

источник

Для разработки модели «как есть» предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии:

o IDEF0 (функциональная модель);
o DFD (DataFlow Diagram);
o IDEF3 (Workflow Diagram).

Создание модели в стандарте IDEF0.

Функциональная модель предназначена для описания существующих бизнес — процессов на предприятии (так называемая модель AS-IS «как есть») и идеального положения вещей — того, к чему нужно стремиться (модель ТО-ВЕ «как должно быть»). Методология IDEF0 предписывает построение иерархической системы диаграмм — единичных описаний фрагментов системы.

Построение модели ИС начинается с описания функционирования предприятия (системы) или отдельной ее части (в нашем случае это страхование населения) в целом в виде контекстной диаграммы. На Рис.2 представлена контекстная диаграмма ИС «Страхование населения»:

Рис.2. Контекстная диаграмма страхования населения

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

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

Рис.3. Диаграмма декомпозиции IDEF0.Страхование населения

В результате дальнейшего разбиения функции «Работа с населением» получаем следующую диаграмму декомпозиции (см. Рис.4):

Рис.4. Диаграмма декомпозиции IDEF0.Работа с населением.

Производим декомпозицию функции «Прием документов и регистрация» и получаем конечную диаграмму(см.Рис.5):

Рис.5. Диаграмма декомпозиции IDEF0.Прием и регистрация документов.

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

Теперь добавляется такой ресурс как БД, с помощью которой можно упростить процесс документооборота в ОАО «Согаз-Мед (см.Рис.6) :

Рис.6.Контекстная диаграмма модели «как должно быть».

На диаграммах «Страхование населения», «Работа с населением» и «Прием и регистрация документов» так же добавился ресурс БД. В ранее уже рассмотренной диаграмме декомпозиции «Прием и регистрация документов» произошли изменения. Теперь прием документов и их проверка-это единый процесс, к результате чего выявляется наличие полиса у клиента. Так же можно отследить дату, когда действие полиса заканчивается и заранее уведомить об этом клиента.(см.Рис.7):

Рис.7. Диаграмма декомпозиции IDEF0.Прием и регистрация документов.

Из модели «как должно быть» следует, что применение в сфере страхования населения БД, заметно уменьшает время обработки не только поступивших от клиентов документов, но и дает возможность более тщательно отслеживать сроки действия полисов, что в свою очередь ведет к благоприятным успехам в работе с клиентской базой и улучшению имиджа компании.

источник

В предыдущем номере «ДО» мы отметили актуальность и значение бизнес-процессов в компании. Теперь определим, по каким принципам проводить их анализ, как правильно использовать полученную информацию и выявить проблемы.

Что описываем?

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

Сбор информации

Перед описанием любого про-цесса определимся с его параметрами:
1. Цель — для чего необходимо четко отлаженное его функционирование.
2. Участники — конкретные исполнители, чьи обязанности создают его основной функционал:

функции, которые они выполняют;
принципы их взаимодействия между собой;
данные, передаваемые ими друг другу.

Обладая этой информацией, приступаем к непосредственному опросу участников. Он проводится в различных формах: письменно или устно, в виде закрытых и открытых вопросов, требующих соответственно однозначного или развернутого ответа. Выбор способа зависит как от личности специалиста, так и от опрашиваемых участников процесса. Самым важным на данном этапе является способность того, кто проводит опрос, найти контакт с опрашиваемыми, «разговорить» их. Некоторые участники стремятся сознательно утаить ряд специфических особенностей выполняемых ими функций. Причины тому самые разные. Например, сотрудник не хочет, чтобы стал известным тот факт, что на выполнение определенного действия он тратит намного меньше времени, чем предполагается его руководством. Или просто он не хочет вносить ясность в выполняемый им функционал, опасаясь, что таковые навыки приобретет кто-то другой. Нередко человек стремится убедить всех в своей исключительности, внушить мысль, что без него ничего не будет работать.
В такой ситуации самый действенный способ убеждения сотрудника — это объяснение, что цель описания процесса, участником которого он является, — только регламентация выполняемых им функций. В результате этого не будут усложнены или значительно видоизменены его «исключительные» функциональные обязанности.

Какой формат выбрать?

Полная информация от всех участников бизнес-процесса позволяет приступить непосредственно к моделированию его схемы. В настоящее время существует множество форматов для описания таких моделей. Каждый из них имеет свою специфику и наилучшим образом подходит для описания конкретного вида бизнес-процесса.
При выборе формата нужно иметь в виду одно обстоятельство: результатом описания должна стать модель процесса, понятная как любому из его участников, так и начальнику подразделения и руководству компании. На начальном этапе следует выбрать тот формат, который позволит описать существующее положение дел в привязке к имеющейся в компании организационной структуре. Такой подход объясняется тем, что на практике понять процесс абстрактно, в отрыве от оргструктуры, бывает затруднительно.
В определенной степени оптимальным считается формат WFD (Work Flow Diagram — Диаграмма потоков работ), когда выполняемые работы привязываются к конкретным сотрудникам, встроенным в организационную структуру компании на описываемом этапе. Можно использовать и различные специализированные программные продукты. Однако такие специальные оболочки, как правило, дорого стоят, и для работы с ними потребуются определенные знания и опыт. Более простой вариант — применение стандартной графической программы. Например, в нашей компании используется Microsoft Office Visio, которая насчитывает значительное число стандартных шаблонов по самым различным разделам: бизнес, расписания, блок-схемы и т.п. При помощи имеющихся в программе инструментов можно описать практически любую схему.
В привязке к существующей оргструктуре удобнее всего использовать так называемую функциональную блок-схему, в которой показываются потоки работ, выполняемых конкретными исполнителями. В ней по горизонтали или по вертикали располагаются столб-цы, соответствующие конкретным должностям, а в теле таблицы при помощи условных обозначений показаны работы, выполняемые ими. Под условными обозначениями понимаются стандартные фигуры, имеющиеся в программе для описания простой блок-схемы: процесс, решение, данные и т.д. WFD позволяет описать бизнес-процесс как совокупность всех составляющих его работ.

Очень удобно, если на схему потоков работ наложить схему потоков данных, которые передаются между исполнителями при выполнении ими своих функциональных обязанностей. Послед-нее описывается так называемым форматом DFD (Data Flow Diagram — Диаграмма потоков данных). Совместное использование WFD и DFD дает очень наглядную картину процесса. А в привязке к организационной структуре получается достаточно исчерпывающая картина процесса в модели «как есть».
Основная опасность, которая подстерегает специалиста при описании процесса, — это соблазн при обнаружении какой-либо нелогичности сразу же оптимизировать этот момент. То есть перейти к модели «как надо». Могут быть ситуации, когда непонятно, кто выполняет и кто ответственен за определенные этапы процесса. В этом случае на стадии описания модели «как есть» лучше в столбце с наименованием должности указывать не одну, а сразу несколько через запятую. Тогда на этапе оптимизации процесса будет легче определиться с тем, кому в реальности выполнять соответствующие функции. В любом случае, при описании модели «как есть» нельзя оптимизировать процесс. Это уже модель «как надо».
Подробнее об этом читайте в следующем номере «ДО».

Максим Бородаенко
директор по коммерческому развитию компании «Авторай»

Андрей Храмов
помощник директора по коммерческому развитию компании «Авторай»

источник

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

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

К основным этапам оптимизации бизнес-процессов можно отнести:

Изучение бизнес-процесса и постановка целей моделирования и оптимизации. Данный этап не имеет формального описания, а лишь формирует общее представление бизнес-процесса. Цели и задачи должны быть регламентированы и быть достижимыми.

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

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

Выработка рекомендаций для решения задач, поставленных перед проведением анализа.

Моделирование и анализ бизнес-процессов «как есть» включает следующие этапы:

1. Создание моделей организационной структуры;
2. Создание вспомогательных моделей (деревья функций, документов, материальных ресурсов и т.д.);
3. Разработка моделей бизнес-процессов верхнего уровня;
4. Проверка адекватности моделей верхнего уровня;
5. Разработка моделей детальных бизнес-процессов (несколько уровней декомпозиции);
6. Проверка адекватности детальных моделей;
7. Создание моделей документов, данных и т.д.
8. Проведение анализа моделей.
9. Формирование отчетов.

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

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

После определения результата следует разобраться с последовательностью действий, составляющих процесс.

Последовательность действий моделируется на разных уровнях абстракции. На самом верхнем уровне показывают только наиболее важные шаги процесса (обычно не более десяти). Затем производится декомпозиция каждого из высокоуровневых шагов (подпроцессов). Глубина декомпозиции определяется сложностью процесса и требуемой степенью детализации. Для того чтобы получить действительно полное представление о бизнес-процессе, надо произвести декомпозицию до атомарных бизнес-функций —хорошо понятных элементарных действий (отдельных операций в ПО или выполняемых человеком), которые нет смысла раскладывать на составляющие. На основе собранной информации строится модель обычного, или оптимального, выполнения процесса и определяются возможные сценарии его выполнения со сбоями. Различные сбои исключительные ситуации — исключения) могут нарушать оптимальный ход процесса, поэтому следует указать, каким образом исключения будут «обработаны», то есть какие действия предпринимаются в случае возникновения исключительной ситуации.

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

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

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

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

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

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

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

Диаграмму окружения процесса, представляющую бизнес-процесс в виде одного действия (то есть не раскрывающую ход процесса), для которого могут быть показаны запускающее процесс событие, необходимые входные данные, результат, роли, показатели эффективности, прерывающие события и компенсирующие процессы, регламентирующие документы, связанные бизнес-цели;

Высокоуровневую диаграмму процесса, показывающую его крупные шаги (обычно не более десяти) и связанные с ними роли;

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

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

источник

Одна картинка стоит тысячи слов

Народная мудрость

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

Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, не важно, идет речь об организации работы склада или об IT системе от лида до заявки. Но в реальности практически никогда ее не оказывается, а потому в процессе изучения и поиска решения поставленной клиентом задачи я также создаю функциональную модель работы компании или определенного процесса (функции) самостоятельно.

Как известно, функциональные модели IDEF0 — это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.

И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя — много-много слов. И понять в итоге, что же происходит, было очень сложно.

А потому идея Сытина была поистине революционной — он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно.

Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERP-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену — это и правда очень сложно.

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

Знаю я также много других примеров, когда графическое моделирование бизнес-процессов помогало в работе как моим коллегам, бизнес-консультантам и разработчикам, так и самим бизнесменам.

Моя работа всегда связана с внесением изменений в существующую систему. А для того, чтобы внести изменения и получить нужный результат, нужно изучить то, что существует уже сейчас. И не важно, что именно мы делаем – настраиваем или устанавливаем с нуля CRM-систему, создаем эффективную ERP-систему, занимаемся интеграцией различных систем для повышения автоматизации работы в целом. В любом случае, для начала, необходимо получить представление о существующей схеме работы, и только после этого можно предлагать какие-то изменения и продумывать варианты решения поставленной задачи.

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

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

→ Пример одного из моих отчетов в текстовом виде

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

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

Но для начала, давайте разберемся с основными понятиями, что такое нотации, зачем они нужны, что такое IDEF0, в чем особенности и преимущества этого метода.

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

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

В общем, нотации можно назвать языком программирования при бизнес-анализе.

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ).

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

Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «черный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные.

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

Входящие и исходящие стрелки точнее было бы называть вводящими и выводящими, так как по-английски они называются Input и Output соответственно. Но особенности перевода и привычные названия выглядят уже так, как сложилось. И все же для правильного понимания терминов важно помнить их значение в данном случае. Это подтверждается еще и тем, что данная нотация создана прежде всего для разработки ПО, и термины переводить правильнее в этой точки зрения.

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

IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.

Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку. А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта.

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

Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи.

Основной блок – «Написать статью».

Пример описания функциональной модели верхнего уровня

Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.

Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создает аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создает на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи. Корректор проверяет материал на ошибки. А программное обеспечение – это те инструменты, которые используют в работе все участники процесса.

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

На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать. Для этого я декомпозирую общий блок «написать статью» на связанные между собой элементы.

В нашем случае работа делится на 4 основных этапа:

Подготовить аудио.
Подготовить текст
Подготовить текст к публикации.
Разместить статью в издании.

Пример описания функциональной модели бизнес процесса второго уровня

На схеме наглядно видно, на каком этапе какие управляющие элементы и какие механизмы задействованы.

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

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

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

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

Без такого наглядного инструмента было бы сложнее определить, какие из блоков можно удалить и, таким образом, оптимизировать работу.

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

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

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

При этом важно понимать, что в результате потребуется 2 нотации. Первая будет отображать бизнес-процессы в виде «как есть». Ее вы создаете на основе интервью и согласовываете каждую детализацию с сотрудниками компании и руководителем. Очень важно, чтобы ваше видение существующих процессов совпало с реальностью, именно для этого и требуется подтверждение на всех уровнях.

Вторая нотация – «как должно быть». Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи.

Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

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

Стандарт IDEF0 включает в себя также общепринятые обозначения, правила, требования к блокам диаграмм, имеет собственную семантику. Подробно ознакомиться с ними можно в документе «Методология функционального моделирования IDEF0».

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

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

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

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

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

Оптимальный вариант – это детализация, достаточная для понимания вопроса, и не более того. Подробная детализация работы каждого подразделения или даже сотрудника может раскрываться при выборе подробного просмотра того или иного процесса. И создается такая структура только если это действительно нужно для работы или принятия решения.

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

Аналогично, если я решу добавить какой-то блок, важно убедиться, чтобы он также имел все необходимые атрибуты. Здесь очень важна внимательность, так как при моделировании сложных бизнес-процессов изменения в одной части модели могут повлечь за собой изменения в другой. Их обязательно нужно внести.

Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок.

Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Самая первая выгода очевидна – это наглядность.

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

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

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

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

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

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

Еще статьи по данной теме:

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

источник

Как только вы наняли первого сотрудника. Вам необходимо объяснить ему задачи и обязанности, обучить, передать все ресурсы для начала работы, ответить на “глупые” вопросы, поставить задачи и проконтролировать их исполнение.

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

Если в компании больше 1 сотрудника, а процессы не прописаны, вот с чем вы скорее всего уже сталкивались:

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

Чем быстрее вы систематизируете бизнес-процессы, тем быстрее выйдите из текущих задач и начнете посвящать время семье или новым проектам. И, что самое интересное, еще больше зарабатывать.

В описании бизнес-процессов есть несколько подходов:

Делаете все сами.
Обращаетесь к эксперту, который уже прописал и внедрил все процессы в своей компании и помогает другим бизнесом.
Обращаетесь в специализированные компании, где каждый сотрудник отвечает за свой объем задач.

Построение и оптимизация бизнес-процессов осуществляется в пять этапов:

Этап 1. Разработка модели организации “как есть”.

Этап 2. Анализ модели организации “как есть”.

Этап 3. Разработка модели организации “как надо”.

Этап 4. Разработка плана перехода из состояния “как есть” в состояние “как надо”.

Этап 5. Внедрение изменений и построение организации “как надо”.

В этой статье я расскажу про первый способ описания бизнес-процессов.

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

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

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

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

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

3-4 этап. Разработка модели организации “Как надо” и плана перехода из состояния “как есть” в состояние “как надо”.

На этом этапе вы прописываете тот идеальный вариант работы компании, который хотите получить. Можно взять вариант “как есть” и прямо на нем вносить необходимые правки. Лучше всего описывать все в наглядном графическом виде, используя программы по составлению mind-карт.

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

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

Чтобы реализовать план перехода, обязательно укажите сроки и ответственные лица. Дело за малым — показать план сотрудникам и объяснить, зачем и почему вы это делаете. Ответственные люди, ориентированные на результат, поддержат перемены, поскольку работать станет намного удобнее и быстрее. А вот ленивые и безответственные любые изменения воспримут в штыки. Будьте готовы к этому.

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

Найдите сторонников изменений в компании и сформируйте “бригаду изменений”, которая будет помогать вам внедрять и контролировать новые процессы.

Время, потраченное на описание и внедрение бизнес-процессов, окупится в несколько раз. Одна из причин отсутствия бизнес-процессов в компаниях — нехватка времени руководителя. Но главная причина в отсутствии понимания “зачем и как это нужно делать”.

источник

Консалтинг при автоматизации предприятий:
подходы, методы, средства

ГЛАВА 12
ПОСТРОЕНИЕ МОДЕЛЕЙ

12.1. Построение и анализ моделей деятельности предприятия

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

модели “как есть”, представляющей собой «снимок» положения дел на предприятии (оргштатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования и позволяющей понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации;
модели “как должно быть”, интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков по совершенствованию деятельности предприятия.

При этом переход от модели “ как есть ” к модели ” как должно быть ” обычно осуществляется следующими двумя способами :

Совершенствование м технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников ( “ легкий ” реинжиниринг).
Радикальным изменением технологий и переосмыслением бизнес-процессов ( “ жесткий ” реинжиниринг). Например, вместо попыток улучшения бизнес-процесса проверки кредитоспособности клиента, может быть следует задуматься, а нужна ли вообще такая проверка? Возможно затраты на такие проверки каждого из клиентов во много раз превышают убытки, которые может понести банк в отдельных случаях недобросовестности (в случае, когда клиентов много, а суммы сделок незначительны)!

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

В рамках создания моделей деятельности должен быть осуществлен:

анализ функциональной деятельности структурных подразделений предприятия;
анализ функционального взаимодействия структурных подразделений;
анализ внутреннего документооборота структурных подразделений;
анализ информационных потоков и информационного взаимодействия структурных подразделений;
анализ применяемых в настоящее время средств автоматизации как в структурных подразделениях, так и на предприятии в целом.

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

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

Результатом проведения анализа и оценки являются предложения по совершенствованию деятельности предприятия, а именно :

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

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

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

В связи с вышесказанным каждая из моделей деятельности должна включать :

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

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

1) Разработка структурной функциональной модели деятельности предприятия:

определение информационных потоков между основными процессами деятельности, связей между процессами и внешними объектами;
оценка объемов и интенсивности информационных потоков;
разработка иерархии диаграмм, образующих структурную функциональную модель деятельности предприятия;
анализ и оптимизация структурной функциональной модели.

2) Разработка информационной модели предприятия:

определение сущностей модели и их атрибутов;
проведение атрибутного анализа и оптимизация сущностей;
идентификация отношений между сущностями и определение типов отношений;
разрешение неспецифических отношений;
анализ и оптимизация информационной модели.

3) Разработка событийной модели предприятия:

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

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

1) Модели позволяют осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности предприятия (так как ее технология содержится в модели) с использованием диаграмм (известно, что «одна картинка стоит тысячи слов»).

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

Ниже приводятся некоторые основополагающие рекомендации по структурированию моделей деятельности.

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

2) Верхний уровень модели должен отражать только контекст системы — взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром и ничего более. В случае построения модели структуры, включающей в себя несколько разнотипных предприятий, на контекстном уровне необходимо отразить каждое из них и их соответствующие взаимосвязи. Например, контекстная диаграмма горно-обогатительного комбината может содержать процессы Автобаза, Карьер, Фабрика и Управление ГОК, контекстная диаграмма регионального банка Сбербанка РФ содержит процессы Территориальное Управление, Типовое Отделение, Типовой Филиал.

3) На втором уровне модели должны быть отражены основные деятельности предприятия и их взаимосвязи. Например, для автотранспортного предприятия одним из решений может быть выделение следующих деятельностей : Эксплуатация автотранспорта, Ремонт и техническое обслуживание, Контроль безопасности, Управление производством, Обеспечивающая деятельность . В случае большого количества деятельностей некоторые из них можно вынести на третий уровень модели. Так Обеспечивающая деятельность может включать в себя Учет кадров, Бухгалтерский учет, Экономическое планирование, Материально-техническое снабжение, Складской учет и т.п. Но в любом случае под деятельности необходимо отводить не более двух уровней модели.

4) Каждая из деятельностей, в свою очередь, должна быть детализирована на бизнес-процессы (желательно, единственного уровня). Например, деятельность по учету кадров включает в себя бизнес-процессы Прием на работу, Увольнение и т.п.

5) Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций. Так процесс Прием на работу содержит в себе функции Прием заявления, Оформление приказа, Регистрация и др. Обычно для моделирования бизнес-функции достаточно 2-3 уровней детализации, которая завершается описанием элементарного алгоритма с помощью миниспецификации.

6) Таким образом, общее число уровней в модели не должно превышать 6-7. Практика показывает, что этого вполне достаточно для построения полной модели деятельности современного предприятия любой отрасли.

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

Первый пример касается автобазы, входящей в состав горнообогатительного комбината и занимающейся перевозкой породы от нескольких территориально разделенных предприятий по добыче руды (карьеров) на аналогичные предприятия по ее обогащению (фабрики). Парк автобазы содержит около 200 самосвалов “ БелАЗ ” грузоподъемностью 120 тонн, работы по перевозкам осуществляются в 3 смены. На каждую смену водителю выписывается путевой лист, содержащий 52 графы для однократного заполнения (хотя реально не все заполняются), при этом 5 граф заполняются многократно в соответствии с количеством погрузок / разгрузок. Кроме этого, на каждом путевом листе должно быть проставлено 17 подписей самых различных лиц, прежде чем он попадает в бухгалтерию автобазы и на его основе производится расчет соответствующих выплат. Даже если на получение каждой подписи и заполнение графы затратить в среднем по одной минуте, то оформление одного путевого листа (не включая его обработку в бухгалтерии) занимает более часа, а в день таких листов в принципе может быть шестьсот ! Конечно, руководство автобазы прекрасно понимало проблему и ставило задачу сократить количество подписей хотя бы до 9-10. После проведения обследования и построения и анализа моделей выяснилось, что ВСЯ ИНФОРМАЦИЯ, за исключением контроля состояния водителя и, частично, самосвала (техническая исправность, медицинский контроль), ДУБЛИРУЕТСЯ в различных первичных документах (прежде всего, в диспетчерской сводке, ведомостях на выдачу талонов и различных накладных на отпуск горючего, масел и т.п.), то есть по своей сути путевой лист является производным документом! После предоставления таких результатов с резюме об уничтожении путевых листов как класса у руководства оставался единственный аргумент — требования ГАИ. Но, позвольте, для таких большегрузных самосвалов требуются специальные дороги, да и ездят они по четко определенным маршрутам карьер-фабрика. Более того, у них отсутствует государственный номер, весь учет ведется в соответствии с гаражным номером (от первого до двухсотого), не говоря уже о том, что за все время длительных командировок автору не встретился ни один инспектор.

Второй пример относится к распределенной диспетчерской службе того же самого комбината. Фактически имеется 8 диспетчерских пунктов (2 автобазы, 3 карьера, 2 фабрики, контора), на которых собирается и сводится одна и та же информация по перевозкам породы : карьер собирает данные по вывозу, фабрика — по разгрузке, автобаза — по перевозке, контора — всю эту информацию по каждому из предприятий, то есть одни и те же данные фиксируются 4 раза ! Более того, все эти данные не совпадают, это связано со спецификой производства : например, в сырую погоду при разгрузке на кузов самосвала может налипнуть до 5 тонн породы ! А поскольку объемы перевозок оказывают существенное влияние на начисляемую зарплату, все эти 8 диспетчеров ежедневно тратят уйму времени, сил и нервов на согласование этих данных (и в конце концов находят компромиссное решение). А дальше начинается самое интересное : с определенной периодичностью (неделя, месяц) специалист-маркшейдер делает замеры, сравнивает их результаты с предыдущими и выдает информацию по вывезенной породе за соответствующий период. И именно эта информация служит основой для начисления зарплаты и формирования отчетов по деятельности!

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

Дополнительную информацию Вы можете получить в компании Interface Ltd.

источник