Эталонные модели бизнес процессов erp систем

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

Одни убирают работы, предусмотренные графиком ППР, вторые используют объем бюджета прошлого года увеличенный на плановый/фактический уровень инфляции (ставка рефинансирования, ставка дисконтирования), третьи вообще не используют бюджет. Как итог всех этих подходов – возрастающие до 40% аварийные работы, аварии, инциденты и др. Передовые же компании при проведении планирования используют риск-ориентированный подход, применяя стратегии «по состоянию», с использованием инструмента контроля и диагностики состояния оборудования. Что же получается у них на выходе? Оптимальный бюджет затрат на ТОиР, высокие показатели надежности оборудования, оперативность реагирования на предотвращение аварий и инцидентов, связанных с неудовлетворительным состоянием оборудования.

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

Эталонные и референтные модели

Процесс «А4 Контроль состояния оборудования»

Цель процесса – предупреждение отказов и предоставление данных о техническом состоянии актива.

Описание процесса представлено в виде диаграммы, разработанной в нотации IDEF0, рисунок 1.

• данные по эксплуатации оборудования;
• база данных оборудования;
• оборудование к диагностике.

• данные по эксплуатации оборудования;
• база данных оборудования;
• оборудование к диагностике.

• А4.1. Обнаружение отклонения параметров работы оборудования;
• А4.2. Анализ дефектов и отказов.

Основными ресурсами процесса служат оборудование к диагностике и классификаторы и справочники. Управление же процессом и его подпроцессами осуществляется на основании Политики и Стандарта по управлению производственными активами, написанными на основании международного стандарта серии ISO 55000.

Владелец процесса – начальник лаборатории диагностики, исполнитель – специалист/инженер по диагностике.

Подпроцесс «А4.1. Обнаружение отклонения параметров работы оборудования»

Целью данного процесса является определение технического состояния оборудования.

Описание подпроцесса представлено в виде диаграммы, разработанной в нотации EPC, рисунок 2.

• данные по эксплуатации;
• база данных оборудования ТОиР.

Подпроцесс включает в себя следующие функции (шаги):

• А.4.1.1. Составление маршрутных диагностических карт;
• А.4.1.2. Автоматическое занесение и сравнение с нормами данных измерений в АСУ;
• А.4.1.3. Анализ симптома;
• А.4.1.4. Планирование работ по диагностике;
• А.4.1.5. Проведение диагностики;
• А.4.1.6. Занесение данных по результатам диагностики в АСУ;
• А.4.1.7. Анализ данных по техническому состоянию оборудования;
• А.4.1.8. Создание заявки на объём работ по ТОиР.

Владелец процесса – планировщик по диагностике, исполнитель – специалист по диагностике или диагност.

Инициирование процесса происходит после наступления следующих событий:

• автоматически зарегистрированы контролируемые параметры в АСУ ТП;
• заявка на диагностику сформирована;
• сводный график работ по ТОиР на неделю утвержден;
• закончено создание/изменение реестра оборудования.

Задача, которую решает выстроенный подпроцесс, это автоматизация внесения данных в АСУ ТОиР, проведение анализа симптомов.

Далее на основании проведенного анализа и графика работ по ТОиР планировщик по диагностике разрабатывает график проведения диагностики с указанием оборудования и вида самой диагностики. Следующими шагами диагност проводит работы согласно этому графику, заносит полученные данные в ИС АСУ ТОиР, производит анализ данных по техническому состоянию оборудования. При необходимости передает проанализированную информацию планировщику по диагностике для создания заявки на объем работ по ТОиР.

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

• А.2.1. Обход оборудования;
• А2.4. Регистрация симптомов/дефектов;
• А4.2. Анализ дефектов/отказов;
• А5.3. Месячное планирование;
• А6.1. Недельное планирование работ по ТОиР.

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

Подпроцесс «А4.2. Анализ дефектов и отказов»

Цель – не допустить отказ или минимизировать риск его повторного возникновения.

Описание подпроцесса представлено в виде диаграммы, разработанной в нотации EPC, рисунок 3.

• данные о техническом состоянии оборудования;
• зарегистрированные дефекты.

Подпроцесс включает в себя следующие функции (шаги):

• А4.2.1. Анализ дефекта/отказа;
• А4.2.2. Присвоение дефекту статуса «не является дефектом»;
• А4.2.3. Определение критичности и мер по устранению дефекта/отказа;
• А4.2.4. Создание заявки на объем работ;
• А4.2.5. Формирование заявки на дополнительное обследование.

Владельцем данного процесса является начальник лаборатории по диагностике, исполнителем – инженер по надежности.

Инициирование процесса происходит при возникновении одного из следующих событий:

• данные о дефекте внесены в систему АСУ ТОиР;
• проблема классифицирована как отказ, не приводящий к инциденту/аварии;
• предотвращение инцидента/аварии можно проводить в штатном режиме.

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

В результате подпроцесса по каждому проанализированному дефекту и/или отказу определены мероприятия с указанием:

• вида воздействия (ТОиР, диагностика);
• объема (МТР, персонал и др.);
• оперативности (годовое, месячное или недельно-суточное планирование).

Качество результата бизнес-процесса «Контроль состояния оборудования» поддерживается за счет:

• высокой квалификации персонала;
• отлаженности и интеграции с другими бизнес-процессами;
• точности, полноты, своевременности получаемых данных;
• использования отлаженных информационных систем: ERP, EAM, MES, АСУ ТП;
• автоматизации процесса;
• применения средств диагностики, т.е. сбор только необходимых данных.

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

Журнал Prostoev.NET № 1(26) 2021
А. Докин, Д. ПАВЛИЧЕНКО, консультанты ООО «Простоев.НЕТ»

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

Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы

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

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

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

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

1. Политические, вызванные несоответствием заявленных целей реализации проекта с внутренними ожиданиями участников проекта
2. Функциональные, вызванные недостатком компетенций участников проекта
3. Технологические, вызванные недооценкой требуемых ресурсов, времени

У меня нет опыта внедрения крупных производственных систем с помощью Agile или каких-то других методологий кроме стандартной «водопадной», которая включает в себя следующие основные этапы:

1. Обследование предприятия, описание бизнес-процессов «как есть», «как будет».
2. Создание модели информационной системы.
3. Разработка и реализация ТЗ.
4. Тестовая эксплуатация.
5. Опытно-промышленная эксплуатация.

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

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

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

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

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

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

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

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

Может это лично моя неудачная практика работы на пром. предприятиях, может это реально существующая тенденция, но не ждите, что фразой «теперь тебе не нужно будет нести расходный ордер на согласование ногами за 3 километра, а можно сделать автоматом в системе за 3 секунды» вы получите восторг в ответ. Рядовой исполнитель, чья работа-то и заключалась 60% времени в беге с документами тут же решит, что его сократят, навалят ему работы, в которой он не соображает либо снизят ему зарплату. Логика в его соображениях не всегда присутствует, но сопротивляемость изменениям рядовой сотрудник может оказать вполне явную. Причем как на этапе сбора требований к системе, когда он будет доказывать ценность именно беготни с бумажками («А МихалКузмич из отдела бюджетирования головной организации сказал, что принимают от нас только скан документа со всеми подписями»), так и на этапе эксплуатации системы, когда он просто втупую будет распечатывать ордера из старой системы и носить их ногами («а мне никто не говорил, что новая система уже работает», «ой, да мне ногами быстрее», «а я отправила в этой вашей системе, а там никто не ответил» и т.д.).

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

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

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

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

Каждый из руководителей ходит к директору подписывать свой план в одиночку. И план-фактный анализ он производит исключительно по своему плану. Целостность картины жизни предприятия при этом теряется, разрывы аналитик признаются фактически неустранимыми, управление топ-менеджерами осуществляется в ручном режиме на основе неактуальных, неполных данных.

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

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

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

Если по факту целевого бизнес-процесса сотрудник отдела продаж сможет сделать только одно коммерческое предложение, то он сделает только одно. Даже если на бумаге вы зафиксируете 10 КП в день.

Источник: habr.com

Создание информационных систем с ориентацией на бизнес-процессы

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

— либо процессов предприятия к ERP-системе;

— либо ERP-системы к процессам предприятия.

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

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

— конфигурация и адаптация;

— тестирование и реализация.

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

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

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

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

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

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

Весь процесс можно представить набором стадий и операций (см. табл. 3.1).

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

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

Стадии и этапы разработки и внедрения

В результате получают следующее:

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

— состав данных, используемых в основных и вспомогательных бизнес-процессах.

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

— наличие лишних процессов, от которых можно отказаться.

— наличие эквивалентных по содержанию, но разных по структуре процессов.

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

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

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

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

— сократить время обработки;

— сократить время планирования;

— улучшить организацию производственных процессов и т.д.

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

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

Контрольные вопросы

1. Приведите классификацию информационных систем.

2. В чем разница между позадачным подходом к созданию информационных систем и процессным.

3. Приведите структуру и схему функционирования функционально-позадачной информационной системы.

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

5. Каковы функции информационных систем с производственной ориентацией.

6. Какова структура и функции ERP-систем?

7. Приведите схему функционирования ERP-систем.

8. Дайте характеристику элементам типовой интегрированной информационной системы.

9. Приведите схему корпоративной информационной системы.

10. Каким образом информационная система влияет на структуру управления предприятием.

Тема 4. Информационные технологии и их базовое программное обеспечение

2. Содержание основных технологических операций

3. Состав сетей, обеспечивающих инфокоммуникационные технологии

4. Основные направления в развитии инфокоммуникационных

5. Формы реализации инфокоммуникационных технологий в

1.Романов А.Н., Одинцов Б.Е. Информационные системы в экономике

Учебное пособие.- М.: Вузовский учебник, 2008.

2. Бочаров Е.П. Интегрированные корпоративные информационные

системы: Принципы построения: Учеб. пособие/Е.П. Бочаров, А.И.

Колдина.- М.: Финансы и статистика, 2005.

3. Информационные системы и технологии в экономике и управлении/Под ред. проф.

В.В. ТрофимоваМ.: Высшее образование, 2007.

4. Экономическая информатика: Введение в экономический анализ

информационных систем.- М.: ИНФРА-М, 2005.

5. Дайитбегов Д.М., Черноусов Е.А. Основы алгоритмизации и алгоритмические языки: учебное пособие.- 2-е изд.- М.: Финансы и статистика, 1992.

6. Румянцев В.Ф., Баркалов С.А., Гуреева И.В., Портных В.А. Информационные технологии в управлении бизнес-процессами.- М.: Институт проблем управления им. В.А. Трапезникова, 2001.

7. Бугорский В.Н. Сетевая экономика.- М.: Финансы и статистика, 2007.

Источник: studopedia.su