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

Описание бизнес-процессов

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

Бизнес-процесс

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

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

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

Понятие описания бизнес-процесса

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

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

Составляющие бизнес-процесса

Говоря о понятии бизнес-процесса, специалисты оперируют и другими терминами.

Анализируя вышеизложенное, можно понять, из чего состоит бизнес-процесс, а именно:

Границы бизнес-процесса — это событие или время, которое служит началом и окончанием БП.

Технологический процесс и бизнес-процесс

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

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

Зачем моделировать (описывать) бизнес-процессы

Описание бизнес-процессов позволяет решать сразу 3 задачи.

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

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

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

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

Иными словами, функциональный подход демонстрирует возможности организации, определяя, что надо делать, а процессный подход описывает технологию достижения нужных целей, давая ответ на вопрос: “Как надо делать?”

Основное преимущество процессного подхода в более высокой результативности работы компании, которая достигается за счёт:

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

Методологии и инструментарий описания бизнес-процесса

При выборе методологии описания бизнес-процессов и инструментария необходимо опираться на цели бизнеса:

Виды бизнес-процессов

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

Участники

Участниками БП называются лица или целые отделения, организации, которые выполняют определённые функции в рамках того или иного процесса.

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

Как описывать бизнес-процессы

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

В описании БП выделяют следующие разделы:

Правила описания БП

Мало знать, как правильно составить описание бизнес-процесса, важно также помнить о критериях, которые подтверждают, что перечень операций является описанием БП, а именно:

Наконец, описание должно быть понятным потребителю.

Этапы внедрения БП

Выделяют 5 основных этапов внедрения:

Сравнение нотаций

Есть 2 достаточно популярные нотации: ARIS eEPS и BPMN.

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

Практика работы с бизнес-процессами

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

Выводы

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

Источник

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

Что бывает без предпроектного обследования?

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

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

Основные вопросы, на которые отвечает обследование

Как говорится, вам надо понять, ЧТО, ГДЕ, КОГДА. А именно:

Зачем нужно писать, почему недостаточно обсудить и проговорить?

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

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

Что должно содержать в себе предпроектное обследование?

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

Результатом исследования может быть целый пакет документов (часть из них приведена в конце статьи). Центральным (и, к сожалению, часто единственным) документом у меня обычно является документ «Концепция системы». Этот документ мы и обсудим в настоящей статьей.

Разрабатывая собственную структуру Концепции, я взял за основу отчет, подготавливаемый согласно ГОСТ 34 на стадии «Формирование требований к АС» (см. стандарт РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»). Но при этом внес свои дополнения.

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

Цель создания (модернизации) системы

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

За несколько лет анализа десятков проектов удалось определить только пять возможных целей создания (модернизации) системы:

Идея системы

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

Сравнение старого и нового

Самым эффективным способом понять суть создаваемой системы — идти как бы от противного.

Для этого необходимо:

На чем собираемся зарабатывать

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

Заинтересованность сторон

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

Описание автоматизируемых процессов

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

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

Юридическое обеспечение

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

Перечень функций

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

Требования к безопасности

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

Выбор варианта реализации системы

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

Другие документы предпроектного исследования

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

Заключение

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

Источник

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

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

1.1. Обследование общих закономерностей функционирования организации.

1.1.1. Цель этапа.

Зафиксировать (идентифицировать) структуру организации и общие закономерности ее деятельности.

1.1.2. Содержание работ.

1.1.2.1. Запрос документов регламентирующих деятельность организации в целом.

Более эффективным запрос может быть если сотрудникам заказчика будет передан “Список областей деятельности” по которым требуется регламентирующие документы.

Общие закономерности для построения такого списка:

1.1.3. Результат.

1.1.3.1. Систематизация информации.

Результатом систематизации информации полученной из регламентирующих документов должен стать отчет отражающий:

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

1.2.1. Цель этапа.

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

1.2.2. Содержание работ.

1.2.2.1. Предварительный запрос информации о функционировании подразделений.

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

Примечание. Форма запроса данных приведена в приложении 1.

1.2.2.2. Составление отчета.

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

1.2.2.3. Подготовка положения о классификации бизнес-процессов.

Положение о классификации бизнес-процессов (далее Положение) отражает верхний уровень деления бизнес-процессов.

Все бизнес-процессы организации классифицируются на основные, обеспечивающие, развития, управления.

Основные бизнес-процессы 1.2.2.4. Уточнение полученной информации о функционировании подразделений.

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

Результаты выполнения этапа должны быть внесены в отчет построенный по структуре приведенной в пункте 1.2.2.

1.2.3. Результат.

Отчет о деятельности подразделений построенный по форме приведенной в пункте 1.2.2.2.

Положение о классификации бизнес-процессов, систематизирующее информацию о бизнес-процессах.

1.3. Детальное обследование бизнес-процессов.

1.3.1. Цель этапа.

Зафиксировать необходимые детали выполнения бизнес-процессов.

1.3.2. Содержание работ.

1.3.2.1. Запрос данных о выполнении бизнес-процессов.

Запрос данных производится у владельца процесса в виде интервью по каждому бизнес-процессу с использованием формы приведенной в приложении 2. Последовательность действий выполнения бизнес-процессов (пункт 10 запросной формы) фиксируются на отдельном листе.

1.3.2.2. Подготовка положений о выполнении бизнес-процессов.

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

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

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

Средства документирования (фиксации информации):

1.3.2.4. Уточнение зафиксированной последовательности выполнения бизнес-процессов.

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

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

1.3.3. Результат.

Положения по бизнес-процессам.

Положение по “родительскому” бизнес-процессу.

Положение по документообороту.

Положение по деятельности Организации.

2. Моделирование.

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose.

Детальное моделирование выполняется на языке UML.

2.1.1. Структурное моделирование.

На этапе структурного моделирования в модели должны быть отражены:

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

2.1.2. Детальное моделирование бизнес-процессов.

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

Детальная модель бизнес-процесса должна включать:

Модели должны быть согласованы с ведущими специалистами организации обладающими необходимыми знаниями.

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

Форма передается для заполнения руководителям подразделений.

Заполнение может выполняться в свободной форме на отдельном листе.

8. Возникают ли проблемы при выполнении процесса” И если да то каковы они:

9. Время выполнения процесса:

10. Последовательность действий выполнения процесса.

Система кодирования и регистрации документов:

Состав документов Положения по документообороту

Табель документооборота

Альбом форм документов

Таблица соответствия форм и документов

Графическая схема документооборота

Состав документов Положения по управлению

Положение по структурному подразделению (данные для разработки)

Матрица процесс-отдел

Положение по организационной структуре

Графическое представление оргструктуры.

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

Принципиальная схема бизнес-процесса (графич.)

Иерархическая схема бизнес-процессов (графич.)

Вовлеченность отделов в бизнес процесс (составляется для каждого бизнес-процесса)

Коды для управления:

Контроль

Детальная схема бизнес-процесса

Составляется в соответствии с нотацией IDEF0 и/или UML

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

Система показателей эффективности бизнес-процесса

Возможности для улучшения бизнес-процессов

Классификации бизнес-процессов

По уровню иерархии:

По вкладу в создание основной стоимости:

Источник