Если рассматривать структуру не как блок-схему с прямоугольниками, в которых написаны должности, а именно как систему, которая позволяет управлять предприятием, то это позволит в дальнейшем избежать большого количества проблем.
Система подразумевает наличие связей:
- функций с операциями,
- операций с процессами,
- процессов со статьями бюджета,
- статьей бюджета с критериями качеств выполнения процессов.
Коммерческая организация представляет собой систему, которая мало чем отличается от любой физической или инженерной системы (механической, электрической, электронной, и т.д.), и, следовательно, к разработке структуры коммерческой системы надо подходить с таких же позиций. Неправильно разрабатывать структуру своей коммерческой организации произвольно. При разработке структуры необходимо придерживаться основных правил разработки и построения систем. Одно из первых основополагающих правил системного анализа: система не может разрабатываться по частям. Или, как сформулировал этот принцип «единства дальних и ближних целей» академик Глушков Виктор Михайлович:
Текстовое, табличное и графическое описание бизнес-процессов
«В новой науке, каковой является кибернетика [было написано в начале 60-х годов], не следует заниматься какой-то конкретной ближней задачей, не видя дальнейших перспектив ее развития. И наоборот, никогда нельзя предпринимать перспективную большую разработку, не разбив ее предварительно на такие этапы, чтобы каждый отдельный, с одной стороны, был шагом в направлении этой большой цели, и вместе с тем, сам по себе смотрелся как самостоятельный результат и приносил конкретную пользу».
С течением времени компания развивается, растет. Накапливаются статистические данные (если, конечно, кто-то их собирает), и, естественно, увеличивается количество проблем. Прибыль снижается из-за изменений внешней среды, рынок заполняется конкурентами и товарами конкурентов. Постепенно приходит понимание, что увеличение доходов и оборотов не приносит существенных результатов, и, даже наоборот: рост оборотов приводит к сокращению прибыли.
И, видя все это, можно предположить, что Собственник:
- Хочет увеличить прибыль;
- Хочет увеличить доходы;
- Хочет снизить затраты;
- Хочет наладить учет;
- Хочет автоматизировать процессы;
- Хочется оптимизировать количество персонала;
- Хочет повысить производительность труда сотрудников;
Можно добавлять еще в этот список «хочется, хочется, хочется…».
С чего начинать? За что браться?
Первое «хочется» — это увеличить прибыль. Причем здесь структура? Какая связь между структурой и прибылью? Прибыль (П) — это разность между Доходами (Д) и Расходами (Р): П = Д-Р. Кто отвечает за прибыль?
За Доходы отвечают Маркетинг и Продажи. За Расходы — все остальные функциональные подразделения: Логистика, Финансы, Производство, и т.д. Желание увеличить прибыль, в соответствии с формулой, требует, чтобы процессы, которые связаны с увеличением доходов и сокращением расходов не существовали за «счет друг друга». Иными словами, чтобы рост доходов не сопровождался ростом расходов со скоростью, превышающей скорость роста доходов.
Урок 1. Создание бизнес-процесса и задачи, отображение карты маршрута.
Поэтому, прежде всего, все функции, связанные и с доходами, и с расходами, надо записать.
Это необходимое условие.
Следующий шаг — на основе функций разработать операции. Операции необходимо нормировать, затем из операций «собрать» процессы. После этого необходимо посчитать, сколько денег удастся сэкономить при выполнении процессов, связанных с расходами. Следующий этап — это моделирование процессов для того, чтобы добиться лучших результатов.
При разработке каждой модели проверяется, получит ли компания планируемую маржинальную наценку и, соответственно, планируемую прибыль. Если результат не устраивает работодателя (Собственника), процессы пересматриваются, и разрабатывается новая модель выполнения процессов. Для того, чтобы у тех, кто отвечает за доходы, не было желания увеличивать доходы, не обращая внимания на расходы, вводится соответствующая система мотивации. Разработка Системы Мотивации — это составляющая разработки структуры. Все то, что написано выше относится к разработке структуры (функции, операции, процессы), определение принадлежности функций к различным структурным подразделениям.
Второе «хочется» — это увеличить доходы. Кто отвечает за доходы? И первый шаг — опять же разобраться с функциями. Необходимо точно ответить на вопрос: Кто определяет прогноз продаж, как это делается? Также необходимо ответить на вопрос: Кто определяет план продаж, что план из себя представляет? Каким образом разрабатывается план продаж?
Есть для разработки плана продаж необходимая статистика? «Учитывают» ли существующие процессы сбор необходимой статистики для планирования продаж. Таким образом, определяются функции и процессы, связанные с доходами. Довольно часто на практике в должностных инструкциях сотрудников, ответственных за продажи, даже не упоминаются функции, связанные с планированием продаж.
И, соответственно, никто даже не задумывается о том, как разрабатывать корректный план продаж. И, кроме того, в системе мотивации сотрудников продаж, нет такого критерия, как отклонение плана продаж от фактических продаж. Эта разность должна стремиться к нулю.
Разработка или корректировка структуры является необходимым условием роста доходов.
Третье «хочется» — это снизить затраты. Многие пытаются снизить затраты, не разобравшись ни с функциями и процессами, которые связаны с затратами, ни со стоимостью этих процессов. Но, если разработать функции, записать их, правильно (в соответствии с правилами логики) разложить по должностям, и затем определить процессы и их стоимость. Затем процессы моделируются.
При разработке необходимо оценить несколько моделей, из которых выбрать оптимальную модель (минимум затрат с соблюдением качества выполнения работ). Для того, чтобы процесс выполнялся, вводится прозрачная и понятная система мотивации, основанная на учете выполнения функций (процессов). Эта работа связана с разработкой структуры.
Четвертое «хочется» — это наладить учет. Как можно наладить учет хаотично, бессистемно выполняемой работы. Если не определены процессы, то какой смысл их учитывать. Если не определены нормы выполнения операций, и, соответственно, процессов, то даже, если и наладить учет, то с чем сравнивать результаты? Для налаживания учета необходимо описать процессы.
При описании процессов обязательно определяются документы: «входа» в процесс и «выхода» из процесса. Для документов определяются все данные, которые надо вносить в эти документы. Поэтому и учет — это следствие разработки структуры, которая включает и описание процессов, и документооборот.
Пятое «хочется» — это автоматизировать процессы. Аргумент точно такой же, как и для постановки учета. Так как, если автоматизировать «беспорядок», то получится автоматизированный беспорядок. Стоит ли это делать, не приведя в порядок функции, процессы, и всю структуру компании?! Автоматизация частями возможна, но в любом случае надо видеть всю «картину» в целом.
Например, если в компании автоматизируют общение с клиентами, внедряя CRM систему, то необходимо понимать, что это только часть. И надо сразу же продумывать, как потом связать все модули: и маркетинг, и продажи, и логистику, и производство, и так далее. Поэтому необходимо сразу продумать всю концепцию всей корпоративной информационной системы, которая должна соответствовать организационной структуре.
Должны быть определены все выполняемые функции. Если в качестве функций будет записано что-то одно, а сотрудники будут делать совсем другое, то, что именно будет контролироваться? Только то, что записано! И получится следующее: если сотрудники будут делать «что-то другое», то автоматизированный контроль покажет только одно: сотрудники ничего не делают, и дальше они будут доказывать, что все-таки что-то они делали, но не то, что записано.
Корпоративная Информационная Система (КИС) отражает определенную структуру бизнес-процессов. При разработке Корпоративной Информационной Системы бизнес-процессы формализуются и структурируются.
Это не означает, что происходит «подстройка» бизнес-процессов под КИС. Сначала определяются функции, затем бизнес-процессы. После определения функций и бизнес-процессов, они:
- Обсуждаются
- Рассматриваются замечания
- Принимаются решения по функциям и бизнес-процессам.
После утверждения бизнес-процессов Корпоративная Информационная Система должна реализовывать принятые решения. То есть автоматизация — это следствие разработки структуры.
Шестое «хочется» — это оптимизировать количество персонала. Можно ли планировать персонал не имея разработанной и обоснованной структуры предприятия? Ответ однозначный — нет. Основная качественная ошибка при управлении персоналом та, что достаточно часто сотрудники не имеют тех навыков, которые требуются им по должности.
При этом мало кто корректно разрабатывает должностные инструкции, в которых описываются и квалификационные требования, выполняемой функции. Очень часто вся эта информация берется из интернета, и не адаптируется к конкретным условиям компании. Основная количественная ошибка при управлении персоналом та, что в Компании существует либо избыток сотрудников в определенных сферах, либо недостаток в других сферах. И та, и другая проблемы — это отсутствие корректной структуры, и прежде, чем оптимизировать количество персонала, необходимо разработать должности.
Седьмое «хочется» — это повысить производительность труда сотрудников. Генри Форд писал в своей книге «Моя жизнь, мои достижения»: «Это разложение всех производственных процессов на самые простые движения ведет к колоссальной экономии времени и материалов…». Производительность труда невозможно повысить, если неизвестна исходная точка.
Исходная точка для повышения производительности труда — это нормы выполнения работ. То есть должны быть определены функции, операции. Операции нормированы — это и есть отправная точка для того, чтобы понять: повысили ли сотрудники свою производительность или нет.
И так можно продолжать довольно долго.
То есть сначала необходимо создать крепкий надежный фундамент, рассчитанный с инженерной точностью, которым является структура. И, после этого, часть проблем решится сама собой, а для оставшейся части задач, корректно разработанная структура, во-первых, поможет их сформулировать, и во-вторых, будет служить основной исходной точкой.
Источник: getaimm.ru
Поиск оптимального пути для выявления отклонений в бизнес-процессе
Любая крупная компания представляет собой множество обособленных или взаимосвязанных процессов, которые решают задачи различной направленности. Как правило, любой процесс является сложным механизмом взаимодействия людей, сервисов или других компаний, от которых зависит конечный результат исполняемого процесса. Перерывы в поставках ресурсов, изъяны в сервисах и алгоритмах, длительные исполнение простых операций или их повторное выполнение и многие другие факторы приводят к дополнительным экономическим издержкам и накоплению негативного клиентского опыта. Таким образом, анализ процессов и устранение недостатков в них — одна из важных составляющих для успешного ведения бизнеса.
Для выявления отклонений в процессе в первую очередь необходимо ответить на вопрос – какая последовательность событий (путь процесса) является оптимальной и приводит к положительному результату с минимальным негативным опытом? Четкое понимание того, что из себя представляет оптимальное исполнение процесса, позволяет строить гипотезы и находить точки для его оптимизации.
В данной статье рассмотрим простой и интуитивно понятный способ определения оптимального пути процесса. Для анализа данных будем использовать язык программирования Python. Если интересно, код и пример анализа к статье можно найти в git-репозитории. В качестве исходных данных будет использоваться процесс возмещения затрат на командировки, который выглядит следующим образом:
Перед началом анализа стоит убедиться, что данные включают в себя только журнал событий по обособленному процессу, на который не влияют сторонние факторы. Объясню, что имеется в виду на игрушечном примере. Процесс выдачи кредита – ипотечный, потребительский и другие, все типы относятся к одному процессу, но на условия оформления и одобрения для каждого из них влияют различные факторы, которые присущи только конкретному типу кредитования. И чтобы избежать мешанины и путаницы, такие данные необходимо анализировать отдельно, в разрезе отдельного типа. Самое простое, что мы можем сделать для нахождения оптимального пути – посчитать частоту для каждой уникальной последовательности и выбрать самую популярную:
ilog = Initial_Log(log, «ids», «events», «time», timeformat=»%Y-%m-%d %H:%M:%S») df_topchain = ilog.get_top_chain_sequences(10)
В данном примере для наглядности привёл срез коротких последовательностей, так последовательность под номером 11 содержит только 5 шагов и встречается в 121 случае. Для статистики, данный лог содержит 7065 уникальных сотрудников, которые прошли 1478 уникальных последовательностей событий.
Самая популярная последовательность встречается 956 раз:
Можно сказать — вот он, идеальный путь, сотрудник направил запрос на командировку и в конце получил выплату с успешным одобрением на всех этапах. Однако такой результат не всегда будет верным. Срез данных, которые выбрали для анализа, может содержать в себе большинство последовательностей с негативным исходом.
Таким образом, необходимо просмотреть топ последовательностей по убыванию, и выбрать ту, которая совпадает с корректным начальным и конечным событием. Встречается следующая проблема, таких последовательностей много, каждая из их содержит различное количество событий. А значит, и процесс осуществляется за различное время и задействует различные ресурсы.
Попробуем другой подход к поиску оптимальной последовательности. Для этого выберем последовательность из таблицы выше, которая, на наш взгляд является правильной. Далее будем осуществлять поиск последовательностей, исходя из трех факторов, которые можем рассчитать из имеющихся данных:
1. Общее время исполнения последовательности. Сортируем последовательности в логе в порядке возрастания общего времени исполнения. Недостатки данного фактора — существуют события, которые напрямую не зависят от самого процесса. Например, время, затраченное на командировку.
Одному сотруднику нужно съездить на конференцию в соседнюю область, другому, провести исследования в Антарктике. Таким образом, такие события могут сильно искажать статистику последовательности.
2. Насколько последовательность похожа на ту, которую мы выбрали. Определяем значение сходства каждой последовательности в логе с выбранной и сортируем в порядке убывания схожести. Недостатки фактора – если имена событий будут представлены в виде индексов (event_1, event_2, event_22…), могут быть неточности с коэффициентами схожести, стоит уделить внимание к выбору алгоритма или переименованию событий. Для определения схожести строк в данном примере используется стандартная библиотека Python – difflib (метод SequenceMatcher). Но советую попробовать библиотеку thefuzz.
3. Насколько часто последовательность встречается в логе. Сортируем последовательности в порядке убывания частот.
Далее выберем из трех отсортированных списков индексы последовательностей и просуммируем их. Таким образом мы получим «вес последовательности», только выбираем с наименьшим весом.
Для примера, выберем для анализа следующую последовательность:
for_compare = [‘Permit SUBMITTED by EMPLOYEE’, ‘Permit APPROVED by ADMINISTRATION’, ‘Start trip’, ‘End trip’, ‘Declaration SUBMITTED by EMPLOYEE’, ‘Declaration APPROVED by ADMINISTRATION’, ‘Request Payment’, ‘Payment Handled’]
И рассчитаем лучшую последовательность, по отношению к выбранной:
op = Optimal_Process(ilog) b, s = op.get_faster_similar_sequence(for_compare, best_seq_ind = 0)
В итоге получим следующую последовательность:
[‘Permit SUBMITTED by EMPLOYEE’, ‘Permit APPROVED by ADMINISTRATION’, ‘Start trip’, ‘End trip’, ‘Permit FINAL_APPROVED by SUPERVISOR’, ‘Declaration SUBMITTED by EMPLOYEE’, ‘Declaration APPROVED by ADMINISTRATION’, ‘Declaration FINAL_APPROVED by SUPERVISOR’, ‘Request Payment’, ‘Payment Handled’]
Как видим, относительно выбранной последовательности у нас добавилось одобрение поездки «Permit FINAL_APPROVED by SUPERVISOR» и одобрение декларации на расходы «Declaration FINAL_APPROVED by SUPERVISOR» руководителем. Что очень похоже на самую популярную последовательность (таблица 3). Разница только в том, что одобрение поездки руководителем осуществляется уже после командировки.
Здесь сразу хочется вернуться к первому фактору, который описали выше. В данном случае время, затраченное на поездку, является случайным фактором, и для полученной последовательности медианное время исполнения события поездки оказалось меньше, чем для самой популярной, по этой причине вес последовательности может быть сильно завышен. Поэтому, если в анализируемом логе присутствуют подобные события, им стоит задавать константное значение, чтобы они не вносили хаос в общую статистику.
Исходя из результатов, можем убедиться, что самая популярная последовательность и есть оптимальный путь процесса. На основе этого можно продолжить дальнейший анализ, фильтровать цепочки событий, которые не входят в оптимальный процесс, и выявлять их причины.
Данная статья не является руководством по исследованию, а лишь одним из примеров, как можно подойти к анализу процесса без использования сложных инструментов. При этом мы попытались выделить основные проблемы, с которыми можем столкнуться при анализе процессов.
Источник: newtechaudit.ru
Модели оптимизированных бизнес-процессов
Рассмотрев математическую модель и проведя ее оптимизацию, мы получили готовые предложения по реинжинирингу, которые опишем с помощью методологии IDEF0, IDEF3 и DFD. На рисунке 2.4 показана контекстная диаграмма. 
Рисунок 2.4 – Контекстная диаграмма Рассмотрим составляющие диаграммы.
Группа «Управление» 1. Приказы руководства; Группа «Входная информация» 1. Задания (содержит план и нормы работ по текущему списку торговых точек); 2. Список торговых точек (полный перечень мест, которые должен посетить водитель-экспедитор); 3. Карта местности в цифровом формате, пригодном для использования информационной системой; Группа «Исходящая информация» 1. Заключенные договоры; 2. Отчетность о проделанной работе; Группа «Механизмы» 1. Водитель-экспедитор; 2. Информационная система; Черный ящик «Деятельность водителя-экспедитора содержит основные бизнес-процессы, которые выполняются в ходе привлечения клиентов и работы с уже существующими. Проведем его декомпозицию (см. рисунок 2.5) 
Рисунок 2.5 – Декомпозиция бизнес-процесса При декомпозиции были выявлены следующие бизнес-процессы: Планировать деятельность – водитель-экспедитор получает задание от супервайзера, список торговых точек и карту местности в электронном виде.
Руководствуясь этими документами он планирует маршруты передвижения. Основные нововведения в этом процессе – это добавление выхода «Пепсико Холдингсльный маршрут передвижения» помимо имевшегося ранее подмножества торговых точек «Текущий список торговых точек», маршрут передвижения до которых ранее определял сам водитель-экспедитор.
Также новым является введение информационной системы как механизма. Доставка товаров– основной процесс в рамках деятельности водителя-экспедитора. Нами он затронут не был, так что в дальнейшем более глубоко рассмотрен не будет. Водитель-экспедитор осуществляет объезд точек сбыта по спланированному маршруту и делает попытки заключить договоры.
Обо всех результатах докладывается начальству. На вход подаются списки торговых точек, задания, а также Пепсико Холдингсльный маршрут движения. На выходе имеем заключенные договоры, заказы клиентов.
Подготовка отчетов– в рамках данного бизнес-процесса водитель-экспедитор систематизирует данные о проделанной работе и сдает их в виде отчетов супервайзеру и более высокому начальству. Все вышеперечисленные процессы осуществляются посредством механизмов «Водитель-экспедитор» и «ИС» под управлением должностной инструкции Перейдем к декомпозиции процесса «Планировать деятельность» (см. рисунок 2.6).
Она будет произведена с помощью методологии IDEF3. 
Рисунок 2.6 – Декомпозиция бизнес-процесса «планировать деятельность» При декомпозиции были выявлены следующие бизнес-операции: Ознакомление с заданием– Водитель-экспедитор изучает список торговых точек, который предоставил ему супервайзер и выбирает те, которые он посетит в текущий день.
Далее может произойти ветвление. Если все точки уже объезжались и набор их неизменен, то можно выбрать готовый маршрут из системы и начать передвижение по нему, либо приступить к планированию нового маршрута.
Выбор созданного ранее маршрута– используя собственную базу данных, информационная система может предоставлять водителю-экспедитору готовые варианты передвижения, отображая их с помощью карты местности. Планирование нового Оптимального маршрута – новый процесс, введенный нами при оптимизации. Отличие от предыдущего положения дел – маршрут планировался «на ходу», по списку точек объезда. Теперь используя карту местности и введенные торговым представителем точки строит на основе заложенных в нее алгоритмов, оптимальный маршрут и выдает его водителю-экспедитору.
Источник: studfile.net
