Аннотация: Стоимостный анализ: объект затрат, двигатель затрат, центр затрат. Свойства, определяемые пользователем (UDP). Диаграммы потоков данных (Data Flow Diagramming): работы, внешние сущности (ссылки), потоки работ, хранилища данных. Метод описания процессов IDEF3: работы, связи, объекты ссылок, перекрестки. Имитационное моделирование: источники и стоки, очереди, процессы.
Стоимостный анализ
Как было указано ранее, обычно сначала строится функциональная модель существующей организации работы — AS-IS (как есть). После построения модели AS-IS проводится анализ бизнес-процессов, потоки данных и объектов перенаправляются и улучшаются, в результате строится модель ТО-ВЕ. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается наилучшая. Проблема состоит в том, что таких критериев много и непросто определить важнейший. Для того чтобы определить качество созданной модели с точки зрения эффективности бизнес-процессов, необходима система метрики, т. е. качество следует оценивать количественно.
Масштабирование бизнеса Desant Consult Карта бизнес-процесса AS IS / TO BE зачем она нужна?
BPwin предоставляет аналитику два инструмента для оценки модели — стоимостный анализ , основанный на работах ( Activity Based Costing, ABC ), и свойства, определяемые пользователем ( User Defined Properties, UDP ). Функциональное оценивание – ABC – это технология выявления и исследования стоимости выполнения той или иной функции (действия). Исходными данными для функционального оценивания являются затраты на ресурсы (материалы, персонал и т.д.). В сравнении с традиционными способами оценки затрат, при применении которых часто недооценивается продукция, производимая в незначительном объеме, и переоценивается массовый выпуск, ABC обеспечивает более точный метод расчета стоимости производства продукции, основанный на стоимости выполнения всех технологических операций, выполняемых при ее выпуске. Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса . Стоимостный анализ основан на модели работ , потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия ( Business Process Reengineering , BPR ). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация наиболее дорогостоящих работ (тех, которые должны быть улучшены в первую очередь ), обеспечение менеджеров финансовой мерой предлагаемых изменений и т.д.
ABC — анализ может проводиться только тогда, когда модель работы последовательная (следует синтаксическим правилам IDEF0 ), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений), другими словами, когда создание модели работы закончено.
БИЗНЕС — МОДЕЛИ И БИЗНЕС — ПРОЦЕССЫ | Саидмурод Давлатов
ABC включает следующие основные понятия:
- Объект затрат — причина, по которой работа выполняется, обычно основной выход работы. Стоимость работ есть суммарная стоимость объектов затрат ( «Сборка и тестирование компьютеров», рис. 8.1);
- Двигатель затрат — характеристики входов и управлений работы («Заказы клиентов», «Правила сборки и тестирования», «Персонал производственного отдела» рис. 8.1), которые влияют на то, как выполняется и как долго длится работа;
- Центры затрат , которые можно трактовать как статьи расхода.
Рис. 8.1. Иллюстрация терминов ABC
При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties ( меню Model ), закладка ABC Units (рис. 8.2).
Рис. 8.2. Настройка единиц измерения валюты и времени
Если в списке выбора отсутствует необходимая валюта (например, рубль), ее можно добавить. Диапазон измерения времени в списке Unit of measurment достаточен для большинства случаев — от секунд до лет.
Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Editor из меню Model (рис. 8.3).
Рис. 8.3. Диалог Cost Center Editor
Каждому центру затрат следует дать подробное описание в окне Definition. Список центров затрат упорядочен. Порядок в списке можно менять при помощи стрелок, расположенных справа от списка.
Задание определенной последовательности центров затрат в списке, во-первых, облегчает последующую работу при присвоении стоимости работам, а во-вторых, имеет значение при использовании единых стандартных отчетов в разных моделях. Хотя BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI, информация о центрах затрат и UDP сохраняется в виде указателей, т. е. хранятся не названия центров затрат , а их номера. Поэтому, если нужно использовать один и тот же стандартный отчет в разных моделях, списки центров затрат должны быть в них одинаковы.
Для задания стоимости работы (для каждой работы на диаграмме декомпозиции ) следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Cost (рис. 8.4). В диалоге Activity Cost указывается частота проведения данной работы в рамках общего процесса (окно Frequency ) и продолжительность ( Duration ). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость . Аналогично назначаются суммы по каждому центру затрат , т. е. задается стоимость каждой работы по каждой статье расхода. Если в процессе назначения стоимости возникает необходимость внесения дополнительных центров затрат , диалог Cost Center Editor вызывается прямо из диалога Activity Properties/Cost соответствующей кнопкой.
Рис. 8.4. Задание стоимости работ в диалоге Activity Properties/Cost
Общие затраты по работе рассчитываются как сумма по всем центрам затрат . При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Если во всех работах модели включен режим Compute from Decompositions (рис. 8.4), подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх (рис. 8.5).
Рис. 8.5. Вычисление затрат родительской работы
Этот достаточно упрощенный принцип подсчета справедлив, если работы выполняются последовательно. Встроенные возможности BPwin позволяют разрабатывать упрощенные модели стоимости, которые, тем не менее, оказываются чрезвычайно полезными при предварительной оценке затрат. Если схема выполнения более сложная (например, работы производятся альтернативно), можно отказаться от подсчета и задать итоговые суммы для каждой работы вручную ( Override Decompositions ). В этом случае результаты расчетов с нижних уровней декомпозиции будут игнорироваться, и при расчетах на верхних уровнях будет учитываться сумма, заданная вручную. На любом уровне результаты расчетов сохраняются независимо от выбранного режима, поэтому при выключении опции Override Decompositions расчет снизу вверх производится обычным образом.
Для проведения более тонкого анализа можно воспользоваться специализированным средством стоимостного анализа EasyABC ( ABC Technology , Inc.). BPwin имеет двунаправленный интерфейс с EasyABC. Для экспорта данных в EasyABC следует выбрать пункт меню File/ Export / Node Tree , задать в диалоге Export Node Tree необходимые настройки и экспортировать дерево узлов в текстовый файл (.txt).
Файл экспорта можно импортировать в EasyABC. После проведения необходимых расчетов результирующие данные можно импортировать из EasyABC в BPwin. Для импорта нужно выбрать меню File/Import/Costs и в диалоге Import Activity Costs выбрать необходимые установки.
Результаты стоимостного анализа могут существенно повлиять на очередность выполнения работ . Предположим, что для оценки качества изделия необходимо провести три работы:
- внешний осмотр — стоимость 50 руб.;
- пробное включение — стоимость 150 руб.;
- испытание на стенде — стоимость 300 руб.
Предположим также, что с точки зрения технологии очередность проведения работ несущественна, а вероятность выявления брака одинакова (50%). Пусть необходимо проверить восемь изделий. Если проводить работы в убывающем по стоимости порядке, то затраты на получение готового изделия составят:
300 руб. ( испытание на стенде)*8 +150 руб. (пробное включение) *4 + 50 руб. (внешний осмотр) *2 = 3100 руб.
Если проводить работы в возрастающем по стоимости порядке, то на получение готового изделия будет затрачено:
50 руб. (внешний осмотр) *8 +150 руб. (пробное включение) *4 + 300 руб. ( испытание на стенде) *2 = 1600 руб.
Следовательно, с целью минимизации затрат первой должна быть выполнена наиболее дешевая работа, затем — средняя по стоимости и в конце — наиболее дорогая.
Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin, настройка которого производится в диалоговом окне Activity Cost Report ( меню Tools/Reports/ Activity Cost Report ) (рис. 8.6). Отчет позволяет документировать имя, номер, определение и стоимость работ , как суммарную, так и раздельно по центрам затрат .
Рис. 8.6. Диалог настройки отчета по стоимости работ
Результаты отображаются и непосредственно на диаграммах. В левом нижнем углу прямоугольника работы может показываться либо стоимость (по умолчанию), либо продолжительность, либо частота проведения работы. Настройка отображения осуществляется в диалоге Model Properties ( меню Model / Model Properties), закладка Display ( ABC Data , ABC Units).
Свойства, определяемые пользователем (UDP)
АВС позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик — свойств, определенных пользователем — (User Defined Properties, UDP). UDP позволяют провести дополнительный анализ, хотя и без суммирующих подсчетов.
Для описания UDP служит диалог User-Defined Property Editor (меню Model/UDP Definition Editor) (рис. 8.7). В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойства. Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Для внесения категории следует задать имя категории в окне New Keyword и щелкнуть по кнопке Add Category.
Для присвоения свойства категории необходимо выбрать UDP из списка, затем категорию из списка категорий и щелкнуть по кнопке Update. Одна категория может объединять несколько свойств, в то же время одно свойство может входить в несколько категорий. Свойство типа List может содержать массив предварительно определенных значений. Для определения области значений UDP типа List следует задать значение свойства в окне New Keyword и щелкнуть по кнопке Add Member. Значения из списка можно редактировать и удалять.
Рис. 8.7. Диалог описания UDP
Каждой работе можно поставить в соответствие набор UDP. Для этого следует щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP. В закладке UDP Values диалога IDEF0 Activity Properties можно задать значения UDP. Результат задания можно проанализировать в отчете Diagram Object Report (меню Tools/Report/Diagram Object Report) (рис. 8.8).
Источник: intuit.ru
Описание бизнес-процессов Как есть (AS IS) и Как должно быть (TO BE)
Если вы занимаетесь бизнес анализом или являетесь бизнес-аналитиком, вы скорее всего сталкивались с требованием описать бизнес процесс в формате AS IS. Что это такое и практический пример использования подхода вы найдете в этой статье.
Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — AS IS и TO BE. И все авторы писали, что сначала необходимо составить нотацию AS IS (буквальный перевод — “как есть”), т.е. как система работает в настоящее время, и только потом приступать к процессу модернизации, т.е. создавать нотацию TO BE (Как должно быть).
Проще говоря, сначала следует изучить, как работает предприятие или отдел сейчас, сделать описание бизнес процесса, и только потом, на основе нотации AS IS, начинать оптимизацию. Но все эти теории хороши, когда есть что описывать по схеме «Как есть». В реальности ситуация чаще всего иная.
Описывать нечего
Если в компании не проводилась ранее оптимизация бизнес-процессов, а это обычная ситуация, нет каких-то четких инструкций, то каждый из сотрудников будет работать по-своему.
Здесь нет ничего необычного. Каждый человек мыслит немного по-своему, у каждого за плечами — собственный опыт. В результате даже самые простые задачи мы все склонны выполнять по-разному.
Например, процесс согласования счета даже в одной организации может выполняться очень по-разному. Кто-то сначала пойдет к начальнику отдела, а кто-то направится сразу в бухгалтерию подписывать счет.
Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами:
– Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом.
– Другой сначала позвонит, все уточнит.
– Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.
Перед ними стоит задача — обработать лиды и сделать план продаж. Возможно, есть даже перечень рекомендаций, как это лучше делать. Но единой системы нет. И люди начинают нарушать последовательность действий, поступать на свое усмотрение и т. д.
Даже при наличии должностных инструкций в реальности они чаще всего пылятся всеми забытые, а сотрудники работают “кто как привык”. В итоге, мы видим, что системы AS IS, т.е. «как есть», не существует. Нет какой-то единой системы, по которой на самом деле люди работают. И описывать, на самом деле, нечего.
Вы, конечно, можете, попытаться составить модель AS IS на основе инструкций. Но она не будет отражать реальность, ведь их массово нарушают. Можете опросить сотрудников, но любая из моделей будет отражать работу только части людей либо что-то «усредненное», что вообще не будет иметь отношения к реальности, т.к. все работают похоже, но — не так.
Описывать незачем
Еще один важный аспект, с которым я столкнулся на практике. О том, что в компании что-то делают неправильно, все и так давно догадываются. Иначе бы вас, как специалиста, не пригласили. И от вас не ждут описания существующих проблем, они часто и так понятны. От вас ждут решения — как надо работать.
Чаще всего клиенты ожидают, что бизнес-консультант придет, осмотрится, опросит людей, после чего выдаст рекомендации, как надо делать, чтобы решить существующие проблемы. Т.е. людям не нужны нотации «Как есть». Им сразу хочется увидеть «Как должно быть».
Зачем создают нотации AS IS?
Создавать нотации AS IS для себя вы можете, это даже может быть удобно и полезно. В конце концов, графика помогает упорядочить мысли, разобраться точнее лично для себя, что и как происходит. Но в рекомендованной последовательности действий указывается обязательный этап предоставления этой нотации клиенту.
Бизнес-консультанту такой подход выгоден с финансовой точки зрения. Большой объем работы повышает ее стоимость. Но нужно ли это заказчику? Он и сам знает, что компания как-то работает, потому что бизнес приносит прибыль и т. д. Вас он нанимает не для того, чтобы за их деньги вы им поясняли, какую схему работы они сами организовали. Им хочется увидеть от эксперта результат, т.е. схему, которая будет работать лучше.
Возникает резонный вопрос. А как без описания того, что есть, вы сможете выдать рекомендации, что нужно изменить? Но ведь вы — специалист, эксперт в своей сфере деятельности, вас потому и позвали, что верят, вы разберетесь и сумеете выдать правильный результат.
Конечно, вы будете вести свои записи. Вполне возможно, что вы даже оформите их в виде нотации, как это и описывают в учебниках. Вы можете использовать эти записи для уточнения каких-то моментов в работе компании. Но этот этап нужен вам, а не заказчику.
Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.
Пример использования нотации AS IS и TO BE
Я сотрудничал с хлебокомбинатом, который имеет цех выпечки, склад и подразделение охраны. При составлении нотации AS IS стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.
Как выглядит процесс:
- Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
- Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
- Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
- Выполняют выпуск хлеба.
- Далее они должны сдавать полученную партию и документы охране.
- Охрана проверяет партию и дает разрешение. Причем, разрешение дается всегда, так как что может охрана? Убедиться, что в партии есть хлеб. Максимум – подсчитать его количество
- Охрана выдает разрешение.
- Цех выпечки передает партию товара на склад.
- Склад принимает товар.
На самом деле, этапы, связанные с действия охраны, не имеют особого смысла, так как охранники не проходили никакие специализированные курсы, в хлебе они вообще не разбираются. Потому и проверить охрана не может ничего, кроме количества. Но количество проверяется еще раз позже при приеме на склад.
Очевидно, что для оптимизации нужно убрать участие охраны в процессе, а контроль выполнять другими методами. Охрана при этом работать на предприятии будет, выполнять контроль периметра, входной контроль и т.д. Но в этом процессе она не нужна.
Процесс TO BE будет таким:
- Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
- Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
- Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
- Выполняют выпуск хлеба.
- Цех выпечки передает партию товара на склад.
- Склад принимает товар.
Источник: savepearlharbor.com
Модели «as is» в нотации IDEF0
После заключения контракта бухгалтерия получает денежные средства от клиента. Подбор материалов осуществляются прорабом в соответствии с планом работ и пожеланиями заказчика. Если предложенные материалы не соответствуют требованиям заказчика, подбор материалов осуществляется заново до тех пор, пока не будет получено согласие заказчика на их использование. После этого осуществляется покупка оговоренных материалов.
Планирование работ осуществляется при участии генерального директора. На данном этапе составляется план работ, формируются поручения для дальнейшего выполнения работ, а также производится закупка материалов.
Непосредственное выполнение работ осуществляется бригадой под руководством прораба с учётом пожеланий заказчика. По окончании данного этапа производится сдача работы.
Приём работы осуществляется директором производственной части. В случае обнаружения брака производятся работы по его устранению, после чего директор производственной части вновь осматривает объект. Если несоответствий больше не выявлено, объект признаётся готовым к сдаче.
После подготовки объекта на сдачу осмотр осуществляет прораб, после чего объект осматривает клиент. Если у клиента нет претензий, то объект считается готовым.
При сдаче готового объекта заказчику подготавливаются акты выполненных работ. При сдаче объекта должен присутствовать генеральный директор, а при приеме — непосредственно заказчик. После приема готового объекта заказчиком, данный объект вводится в эксплуатацию.
Заключение
Прежде чем пытаться улучшить деятельность предприятия, выбрать, а затем внедрить информационную систему, необходимо проанализировать, как работает предприятие в настоящее время. Для анализа необходимо знать не только как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом рабочем месте. Один человек, как правило, не обладает такой информацией. Следовательно, для анализа деятельности предприятия нужно собрать знания множества в одно — создать модель деятельности предприятия.
В результате обследования предприятия строится функциональная модель существующей организации работы – «as is». На основе модели «as is» достигается консенсус между различными единицами бизнеса по тому, «кто что сделал», и что каждая единица бизнеса добавляет в процесс. Модель «as is» позволяет выяснить, «что мы делаем сегодня» перед тем, как перейти на то, «что мы — будем делать завтра».
Внедрение информационной системы неизбежно приведет к перестройке существующих бизнес-процессов предприятия. Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот, отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат) и входу (объекты или информация используются нерационально) и т.д.
Список используемой литературы
1. В.Г.Пожидаев. Методы и средства проектирования информационных систем. – Калининград: КГТУ, 2003 г.
2. И.Д.Рудинский. Технология проектирования автоматизированных систем обработки информации и управления. – М: Горячая линия телеком, 2011 г.
Источник: mydocx.ru
