Методы документирования бизнес процессов

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

Метод описания процессов IDEF3 (Integrated computer aided manu­facturing DEFinition) был разработан для документирования и анализа процессов в существующих или проектируемых системах. Метод поддер­живает как процессно-ориентированное, так и объектно-ориентированное представление информации и позволяет документировать знания о процес­сах и событиях в форме, близкой для человеческого восприятия. Метод был разработан таким образом, чтобы:

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

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

Документирование бизнес-процессов. Часть 1

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

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

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

Быть применимым в различных областях (таких, как проектирова­ние, производство, логистика, торговля и т.д.).

7. Поддерживать интеграцию с другими методами семейства IDEF. IDEF3 достигает этих целей, концентрируясь на описании того, как

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

Кроме IDEF3, являющегося стандартом де-факто в проектировании бизнес-процессов, довольно широко распространены и другие методы документирования, такие, как SADT (Structured Analysis and Design Technique), SA/SD (Structured Analysis and Structured Design) и др.

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

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

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

Методы построения архитектуры бизнес-процессов компании

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

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

Средства для создания диаграмм и инструментарий низкого уровня (Micrografx: ABC Flowcharter; Scitor: Process Charter; High Performance Systems: iThink) позволяют частично или полностью упростить задачу графического изображения бизнес-процессов.

Средства описания потоков работ (Action Technologies: Action-Workflow Analyzer; Viewstar: Process Architect) помимо документирования бизнес-процессов позволяют подготавливать проекты по изменению биз­нес-процессов.

Средства имитационного моделирования и анимации (CASI: Mod-sim; Systems Modelling: Arena; ProModel: ProModel; Gensym: ReThink) делают возможным имитационное моделирование с помощью графических средств, библиотек специализированных подпрограмм и специализирован­ных языков.

4. CASE, объектно-ориентированные инструментарий и средства быстрой разработки приложений (Ptech: Framework; Oracle: Designer 2000; Popkin: System Architect) ориентированы в основном на разработчи- ков информационных систем.

5. Интегрированные многофункциональные средства, автоматизирую- щие основные этапы проведения реинжиниринга бизнес-процессов (Соо- per Meta Software: Workflow Analyzer; Protosoft Inc.: BDF; Gensym: ReThink + G2), включают собственную методологию, многопользовательский доступ к инструментарию по документированию бизнес-процессов, стыковку со средствами быстрой разработки приложе- ний и даже средства имитационного моделирования и анимации.

Источник: studfile.net

Шесть советов по документированию процессов

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

Файл будет накапливать черновики текста и одновременно играть роль «напоминалки». Еще один способ начать – это сообщить вашим коллегам точную дату презентации документа в его первой редакции (оптимальным сроком я считаю 5 – 15 дней). Таким образом вы излечитесь от «откладывания в долгий ящик» и сможете эффективно мобилизовать свои силы и распределить время. Совет 2. Держитесь золотой середины!
Иногда вы прекрасно представляете себе процесс от и до, но все же не можете уловить нужный уровень детализации описания. Помните, что ваше изложение не должно быть всеохватным, а сам документ не стоит превращать в «энциклопедию русской жизни». Ваш уровень – это средний уровень, ни слишком краткий, ни слишком подробный. Экономьте время ваших читателей и свое собственное.

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

Используйте знания ваших коллег, подчиненных, руководителя, чтобы получилось «объемное» изображение процесса. Консультации с рабочей группой можно проводить в два этапа: до написания текста (предварительно) и после. Очень хорошо, если результаты консультаций будут зафиксированы в протоколах или электронной почте. Совет 5. Знакомьте с регламентом!
Очевидно, что утвержденный регламент должен исполняться. И скорее всего, именно на вас как автора ложится приятная обязанность познакомить с документом участников процесса, исполнителей. Лучше это делать коллективно – на собрании группы или отдела (предварительно можно разослать документ по электронной почте, разместить на доступном электронном ресурсе и т.п.).

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

Если вы не сможете ответить на какой-то вопрос сразу, возьмите тайм-аут на поиск ответа. Результаты собрания неплохо было бы фиксировать в специальном реестре (хотя бы на уровне «документ доведен до участников, обсуждались вопросы такие-то»). Подготовьте вопросы по документу, которые можно будет задать на следующем собрании. И не забывайте информировать участников процесса о коррективах, которые вносите в документ. Совет 6. Изменения – это хорошо!
Всё в нашей жизни меняется, и процесс, который вы описали, не является исключением. Если ваша компания развивается, то когда-нибудь настанет время и для его пересмотра. Будьте готовы к этому. Не относитесь к вашему творению как к догме, умейте вовремя уловить необходимость корректив.

Время от времени возвращайтесь к написанному, сверяйте с реальностью, узнавайте мнение участников процесса (тех, кто работает по этому документу). Очень хорошей практикой является аудит по документированному процессу (аудитам посвящен отдельный стандарт семейства ISO – 19011:2002). Не забудьте, что изменение в регламенте – это, по сути, создание его новой редакции.

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

Если ваши изменения не принимают – стоит обсудить с оппонентом лично или, в крайнем случае, по почте причины возражений и найти компромиссное решение. Возражений больше нет? Тогда представляйте измененный документ на утверждение! Надеюсь, что мои советы помогут вам справиться с созданием регламентов. Удачи!

Источник: www.klerk.ru

Документирование и моделирование бизнес-процессов

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

Метод описания процессов IDEF3 (Integrated computer aided ma­nufacturing DEFinition) был разработан для документирования и анализа процессов в существующих или проектируемых системах. Метод поддерживает как процессо-ориентированное, так и объект­но-ориентированное представление информации. Метод был разрабо­тан таким образом, чтобы:

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

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

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

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

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

6. Быть применимым в различных областях (таких как проекти­рование, производство, логистика, торговля и т. д.)

7. Поддерживать интеграцию усилий с другими методами семей­ства IDEF.

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

Глава 6. Структуры и процессы эффективного менеджмента

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

Кроме IDEF3, являющегося стандартом де-факто в проектирова­нии бизнес-процессов, довольно широко распространены и другие ме­тоды документирования, такие как SADT (Structured Analysis and Design Technique), SA/SD (Structured Analysis and Structured De­sign) и др.

Более продвинутым (но и более затратным) способом документи рования бизнес-процессов является их имитационное моделирование с помощью компьютера. Термин «модель» используется для обозна­чения абстракции предмета или состояния вещей, т. е. модель пред­ставляет собой идеализированную систему объектов, свойств и отно­шений, которая разработана для имитации в определенном контексте поведения реально существующей системы.

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

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

Существует огромное количество программных продуктов для ре шения вышеупомянутых задач, которые можно разделить на 5 кате­горий:

1. Средства для создания диаграмм и инструментарий низкого уровня (М icrografx: ABC Flowcharter; Scitor: Process Charter; High Performance Systems: iThink) позволяют частично или полностью упростить задачу графического изображения бизнес-процессов.

2. Средства описания потоков работ (Action Technologies: Action-Workflow Analyzer; Viewstar: Process Architect) помимо документиро вания бизнес процессов позволяют подготавливать проекты по изме­нению бизнес-процессов.

3. Средства имитационного моделирования и анимации (CASI: Modsim; Systems Modelling: Arena; ProModel: ProModel; Gensym: ReThink) делают возможным имитационное моделирование с помо

И. И. Мазур, В. Д. Шапиро, Н. Г. Ольдерогге. Эффективный менеджмент

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

4. CASE, объектно-ориентированные инструментарий и средства быстрой разработки приложений (RAD) (Ptech: Framework; Oracle: Designer 2000; Popkin: System Architect) в основном ориентированы на разработчиков информационных систем.

5. Интегрированные многофункциональные средства, автоматизи­рующие основные этапы проведения реинжиниринга бизнес-процес­сов (Cooper Meta Software: Workflow Analyzer; Protosoft Inc.: BDF; Gensym: ReThink + G2), включают собственную методологию, многопользовательский доступ к инструментарию по документированию бизнес-процессов, стыковку со средствами быст­рой разработки приложений и даже средства имитационного модели­рования и анимации.

Источник: megaobuchalka.ru