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

Любое действие должно быть оправданно целью. Это относится и к описанию бизнес-процессов при внедрении информационной системы на складе. То есть с самого начала встает вопрос: описывать ли бизнес-процессы вообще?

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

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

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

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

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

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

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

Характеристика бизнес-процессов

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

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

Бизнес-процессы структурируются:

— по отношению к получению добавленной ценности продукта или услуги;

— по видам деятельности или составам работ.

По отношению к получению добавленной ценности продукта или услуги идет подразделение на:

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

По видам деятельности или составам работ идет подразделение на:

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

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

Составление бизнес-моделей

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

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

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

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

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

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

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

Поэтому чтобы сократить риски ошибок в процессе моделирования, имеет смысл определить:

  • уровень детализации моделирования;
  • наиболее приоритетные условия протекания процесса (это повлияет на способ описания бизнес-моделей и выбор программы для моделирования);
  • будете вы описывать процессы в специальной программе или в соответствии с принятыми в компании требованиями.

Стандарты подготовки бизнес-процессов

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

Разберем наиболее распространенные средства для описания бизнес-моделей.

Стандарт ARIS

Стандарт ARIS (Arhitecture of Integrated Information System) разработан германской фирмой IDS Scheer. Эта методика моделирования основывается на теории построения интегрированных информационных систем, определяющих принцип визуального отображения всех аспектов функционирования анализируемой компании.

ARIS поддерживает четыре типа моделей:

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

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

Основная бизнес-модель ARIS — eEPC (extended Event-driven Process Chain).

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

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

Метод функционального моделирования SADT (IDEF0)

Метод SADT (Structured analysis and Design Technique) считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы формируют значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.

В соответствии с этими принципами бизнес-модель должна выглядеть следующим образом:

  1. Верхний уровень должен отражать только контекст системы — взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.
  2. На втором уровне модели должны быть отражены основные виды деятельности (тематически сгруппированные бизнес-процессы) предприятия и их взаимосвязи.
  3. Дальнейшая детализация осуществляется посредством бизнес-функций — совокупности операций, сгруппированных по определенным признакам. Бизнес-функции детализируются с помощью элементарных бизнес-операций.

Метод SADT в наибольшей степени подходит для описания процессов верхнего уровня управления.

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

Метод моделирования процессов IDEF3

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

Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.

Как и в методе IDEF0, основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели — действие, или в терминах IDEF3 «единица работы». Существенные взаимоотношения между действиями изображаются с помощью связей. Все связи являются однонаправленными. Завершение одного действия может инициировать начало выполнения сразу нескольких действий, или, наоборот, определенное действие может требовать завершения нескольких других действий. Соединения разбивают или соединяют внутренние потоки и используются для изображения ветвления процесса:

  • разворачивающиеся соединения используются для разбиения потока;
  • сворачивающие соединения объединяют потоки.

В методе IDEF3 устранен основной недостаток IDEF0 — трудная совместимость нескольких процессов. Однако метод стал более труден для восприятия.

Выводы

Возможно, после описания средств для создания бизнес-моделей сама программа WMS покажется вам простой и доступной. Но на самом деле средства моделирования не так уж сложны, как кажутся. Важно просто понимать, зачем все это нужно. А описывать бизнес-процессы вы можете в любом удобном формате, делать графические изображения в Excel или Visio и т.д. Главное — не забывать основные цели бизнес-моделирования перед внедрением WMS:

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

Имея четкое представление о том, что есть сейчас, что обязательно нужно сохранить и что именно вы хотите получить, можно переходить к следующим этапам — выбору программы, планированию бюджета и принятию решения нужна ли вам помощь консалтинговой компании при внедрении. Это уже темы следующих статей цикла.Автор: Оксана АБРАМОВА Источник: skladpro.ru