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

 

Вопрос оптимизации бизнес-процессов за счет их автоматизации – вечная тема. Можно ли натянуть систему на процессы (а «сову на глобус»), или лучше подстроить процессы под систему (и «запихнуть в сову глобус с пинка»)?

 

 

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

Потому что если почитать определение бизнес-процесса, то это:

• устойчивая регулярная деятельность;

• выполняется устойчиво по определенным правилам;

• выполняется циклично.

Т.е. бизнес-процесс подразумевает, что у нас уже есть определенные правила и устойчивая последовательность действий. И чтобы бизнес-процесс автоматизировать, нам нужно иметь эти правила и эту последовательность. А если процесс не выстроен, то зачем мы это автоматизируем – вообще непонятно.

 

 

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

 

 

Бизнес-эффективность означает, что:

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

• Если мы хотим удовлетворять заказчика минимальными усилиями, у нас должны быть четкие правила, чтобы не думать – “направо нам пойти или налево”.

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

 

 

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

Это значит, что изменение бизнес-процессов при их автоматизации практически неизбежно, но менять их нужно осознанно. Об этом мы и поговорим.

 

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

 

 

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

Первая область рассмотрения бизнес-процесса – это так называемый посубъектный анализ:

• мы выявляем участников бизнес-процесса;

• определяем, какие функции и роли они выполняют.

 

 

Вторая область – это функциональный анализ:

• здесь мы определяем действия – что конкретно мы делаем;

• пользу этих действий;

• а также логику – насколько эти действия вообще обоснованы.

 

 

И третий разрез – это информационный анализ:

• мы должны посмотреть, какие данные используются для выполнения этих действий;

• как эти данные изменяются;

• и насколько они достоверны – можем ли мы вообще перепроверить эти данные. Это тоже очень важно.

Рассмотрим каждую область подробнее.

 

Посубъектный анализ

 

 

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

Здесь мы смотрим:

• С кем эти должности взаимодействуют – ходят ли они через голову при взаимодействии, например, со склада сразу к финансовому директору.

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

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

 

 

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

• Мы смотрим классическую органиграмму – структурное отображение организации: должности, роли подчинение «кто, кому, зачем».

• Проводим функциональный анализ – смотрим матрицу ответственности или функциональную матрицу. Какой роли каждая должность отвечает, какие конкретно функции и задачи в рамках должности выполняются: ответственный, соисполнитель, контролер и так далее.

• Смотрим, в каких процессах человек участвует – есть ли у него смешение, когда он одновременно и в процессе управления, и в процессе исполнения, и еще в какой-то вспомогательной деятельности.

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

 

 

Что мы можем здесь увидеть? Например, процесс продажи:

• Менеджер принял запрос клиента, подготовил КП и за согласованием скидки пошел сразу к директору компании. Такое часто бывает.

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

• И следующий шаг – сборка заказа. И там тоже может участвовать менеджер продаж

 

 

Что мы можем оптимизировать:

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

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

• При этом скидки и условия скидки нужно согласовывать с тем, кто за финансовый результат отдела отвечает – с начальником отдела.

Простая зона оптимизации.

 

 

Какие технологии мы для этого используем:

• Передача полномочий и прав – классическое делегирование.

• Перераспределение ответственности.

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

 

 

Какие инструменты мы можем использовать в информационной системе:

• Конечно, матрица ролей и прав доступа, которая должна коррелировать с оптимизированной матрицей ответственности.

• Настройка отчетов и уведомлений по событиям для вышестоящего руководства.

• Правильная настройка правил согласования. Например:

  • Ознакомление, которое не блокирует процесс – чтобы процесс шел быстрее.

  • Параллельное согласование – для сокращения сроков.

  • Жесткий регламент по времени согласования – если вовремя не согласовал, процесс движется дальше.

Все это позволяет ускорить процессы.

 

Функциональный анализ

 

 

Функции – это совокупность действий в определенной предметной области: финансы, маркетинг, производство, продажи и так далее.

Что анализируем:

• Смотрим на отсутствие полезного результата. Человек что-то делает, но непонятно зачем. Это так называемые «ложные операции». Сюда можно отнести пример,когда договор согласует служба безопасности. Зачем? На всякий случай. А процесс при этом затягивается.

• Дублирование, когда одну и ту же функцию выполняет несколько человек параллельно – непонятно почему и по каким правилам.

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

 

 

Инструменты, которые мы можем использовать:

• Диаграммы потоков работ – смотрим последовательность действий.

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

• Регламенты и бизнес-правила – политики, положения и так далее.

 

 

Давайте посмотрим, какие здесь могут быть неоптимальности.

Например, на слайде показан процесс согласования предложения для клиента.

• Приходит запрос на подготовку коммерческого предложения от клиента, и параллельно одно и то же КП начинают составлять два исполнителя.

• Дальше идет согласование скидки – сначала с начальником отдела, а потом еще и с директором.

• Потом происходит согласование договора и оформление заказа.

Что мы здесь видим?

• Дублирование функций по непонятным правилам.

• Двойная процедура согласования непонятно зачем – директор согласует скидку после начальника. А с какой целью? Не доверяет?

 

 

Как это можно оптимизировать:

• Во-первых, мы должны четко закрепить ответственность за подготовку коммерческого предложения за конкретным менеджером

• И мы, например, можем ввести правило, жестко регламентировать в системе условие ветвления:

  • если скидка, которую хочет клиент, больше 10%, тогда идем за согласованием к директору;

  • если скидка, которую хочет клиент, меньше 10% – делегируем согласование начальнику отдела, не тратим лишнее время.

 

 

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

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

• Сегментация и настройка сценариев выполнения процессов в зависимости от сегмента.

• Разновидности бизнес-процессов в зависимости от введенных системных ограничений: лимиты, ценовые матрицы, вариативности скидок и так далее.

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

 

Информационный анализ

 

 

Теперь поговорим про информационный анализ.

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

Есть четыре критерия анализа информации, 4 «Н»:

• Несвоевременность – когда информация не поступает вовремя.

• Недостаточность – когда данные неполные.

• Невостребованность – когда у нас огромный отчет по всем показателям, половину из которых никто не читает, но зачем-то их требуют.

• Недостоверность – когда информацию невозможность проверить. Например, когда отчет составляется в Excel, я спрашиваю: «А откуда вы это взяли?» Мне отвечают: «Руками внесли».

 

 

Инструменты, которые мы используем для информационного анализа:

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

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

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

 

 

Пример неоптимальности передачи информации:

• От клиента приходит запрос на изготовление какого-то изделия.

• Конструкторская служба проектирует это изделие.

• Производство оценивает, можем ли мы вообще изготовить это изделие за те деньги, которые клиент готов заплатить.

• Коммерческая служба согласовывает проект изделия и сроки с клиентом.

• Дальше, по идее, отдел закупок должен закупить в производство сырье или материалы, комплектующие, чтобы произвести то, что нужно.

• И производство потом выполняет этот заказ.

Зачастую в это время информация продолжает меняться:

• Конструктора – творческие люди, они параллельно продолжают думать: «А чего бы нам не усовершенствовать спецификацию?», – и вносят в нее изменения.

• У клиента тоже что-то могло поменяться, он говорит: «А мне другие характеристики нужны».

А закупки-то уже сырье и материалы закупили. И в производство заказ поставили. И вот с этим приходится работать.

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

 

 

Как нужно решать такую ситуацию?

• Конечно, в системе есть информирование о корректировках заказов, но все равно есть точка невозврата. Поэтому первое правило позаказного производства – это предоплата от клиента. Клиент деньги заплатил, он уже несет ответственность за изменения.

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

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

 

 

Какие инструменты оптимизации потоков данных в принципе можно использовать:

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

• Политика «внутреннего потребителя» – проверка данных по месту использования. Если производство в спецификации поставило статус «Согласовано к производству», значит все: мы ее взяли в производство, мы теперь за нее отвечаем.

• Детальная декомпозиция данных и связей между разными данными: какие данные куда передаются и как трансформируются.

 

 

Какие инструменты мы используем в системе:

• Настройка регламентных сроков.

• Матрицы соответствия и трансформации данных. Это когда одни и те же данные для разных получателей должны отражаться по-разному. Классический пример – регламентированный и управленческий учет: разные статьи и разные правила трансформации первичных данных операционной деятельности.

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

• Обязательно маршрутизация движения цифровых документов с возможностью drill down – чтобы мы отчет получили, из него провалились до первичной информации и посмотрели, откуда мы получили эти показатели. А для этого нужна декомпозиция данных и маршруты их движения и трансформации.

 

А теперь самое интересное – посмотрим на системный анализ и оптимизацию бизнес-процессов «сверху»

 

Мы с вами разобрали посубъектный, функциональный, информационный анализ. Но еще есть системный анализ и системная оптимизация процессов.

 

 

Если рассматривать организацию как некую систему, в ней есть:

• Различные взаимосвязанные между собой бизнес-процессы:

  • базовые исполнительские процессы;

  • управленческие процессы, которые формируют ограничения;

  • вспомогательные процессы, которые обеспечивают ресурсами.

• У системы есть вход, деятельность и выход. И управление системой производится по определенным правилам – в виде цикла, основанного на обратной связи:

  • мы смотрим, что мы получили на выходе;

  • сравниваем, насколько это соответствует тому, что мы запланировали на входе;

  • и производим корректирующие действия.

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

 

 

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

Здесь мы должны проанализировать:

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

• Межфункциональные связи между процессами – когда один процесс затрагивает разные области, перетекая из закупок в продажи, из продаж в производство и т.д. На конференции «Анализ & Управление в ИТ-проектах» я проводила мастер-класс по сквозному планированию – это классический пример процесса с межфункциональными связями.

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

• И мы должны проанализировать, есть ли у нас обратная связь и вообще реакция на отклонения – как она совершается и за счет чего.

 

 

Инструменты, которые мы используем:

• Смотрим на жизненный цикл компании – на какой стадии компания находится. Если компания только-только создается и при этом просит оптимизацию и автоматизацию бизнес-процессов – это не сработает. Новые бизнес-процессы стабилизируются год-полтора. Максимум, что можно сделать на этом этапе: внедрить типовую систему, поработать в ней, осознать, что на самом деле надо. Какая оптимизация и выстраивание бизнес-процессов, если вы на рынке начинаете осознавать себя, как субъекта рыночной деятельности?

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

• Смотрим показатели отчетности на разных уровнях – итоговые и промежуточные отчеты по контрольным точкам и по отклонениям.

• Внутренние регламенты и правила:

  • Есть ли какие-то бизнес-правила, насколько они четкие?

  • Есть ли у нас какие-то внутренние регулярные аудиты деятельности?

  • Есть ли у нас проекты управления развитием? И так далее

 

 

Как оптимизируем деятельность? Основные способы:

• Инжиниринг, реинжиниринг и совершенствование бизнес-процессов.

• Изменение организационной структуры.

• Внедрение системы управления по KPI.

• Мотивация

• и так далее.

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

 

 

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

• Системный анализ деятельности – организация как система, виды процессов и так далее.

• Система сбалансированных показателей, дерево связанных показателей.

• Бенчмаркинг – если кто-то может использовать опыт сходных рынков.

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

 

 

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

• Есть группа процессов, которая называется «Управление развитием». В ней есть:

  • внешнее развитие – маркетинг;

  • и есть внутреннее развитие – это регулярная деятельность по системному анализу и улучшению бизнес-процессов, желательно не доводя до реинжиниринга.

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

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

 

 

Есть такое понятие – Business Process Management System. Оно используется в двух значениях.

• Есть Business Process Management System как информационная система – специализированное программное средство для управления бизнес-процессами.

• И Business Process Management System как деятельность – система анализа и совершенствования бизнес-процессов.

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

 

Заключение

 

 

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

Но в этой области тоже есть правила и технологии – их использование помогает бизнес-процессы автоматизировать.

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

 

Вопросы и ответы

 

При автоматизации процессов оптимизация уже должна быть, или она должна уйти на второй план, или это должно быть в параллели?

Все зависит от цели автоматизации. Спрашиваете это у заказчика.

Если у заказчика в принципе все хорошо, и для него автоматизация – это снижение ручного труда, тогда оптимизация будет основана на использовании системы. В системе же уже есть определенные правила и best practice – этого может быть достаточно.

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

Есть еще один последний тренд в проектах перехода с УПП на ERP, когда говорят: «У нас в УПП был бардак, и сейчас мы при переходе на ERP хотим, чтобы у нас еще и все процессы улучшились».

Вы при оптимизации бизнес-процессов замеряете какие-то показатели или метрики – как было, как стало? И если замеряете, то какие?

Если говорить про метрики, которые связаны с бизнес-процессом, то можно замерять скорость. Например, скорость согласования документов при внедрении системы 1С:ДО.

Но есть метрики, которые не всегда связаны с бизнес-процессами. Например, изменение объема продаж может быть связано с изменением бизнес-процесса через контроль и управление работой продавцов, а может быть связано просто с изменением рыночной ситуации – например, импортозамещение. Это бизнес-процессы помогли или так ситуация сложилась? Непонятно.

Поэтому с метриками сложно.

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

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

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

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

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

Из моего опыта, если вы разговариваете с человеком на языке его боли, его потребности, его вовлекать не надо. Я когда прихожу в производство, начинаю говорить: «Ребята, у вас проблемы с заказами есть?» Они говорят, что есть. Я спрашиваю: «У вас же бывают ситуации, когда вам постоянно меняют спецификации?» И всё, – они меня однозначно поддержат в том, что нужно вводить регламент изменения конструкторской документации.

Не надо приходить и говорить: «Вы делаете неправильно, надо делать по-другому!» Надо изначально выяснять проблемы, потребности, пытаться поговорить с людьми про их боли, и тогда вовлечение происходит естественным путем.

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

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

• Мы должны раздробить проект на программу проектов – “есть слона” не целиком, а частями. И внедрять технологию управления этой программой проектов поэтапно.

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

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

• А потом уже либо открываете проект изменения и развития системы, либо работаете с ними в режиме сопровождения. Это зависит от скорости изменений и от объективности изменений процессов.

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

Как вы подходите к составлению бизнес-процессов «как есть» перед тем, как начать их оптимизировать? Вы их все досконально изучаете либо берете только один кусочек?

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

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

• Дальше мы заказчиком определяемся, какие процессы берем в детальный анализ для будущих улучшений, и как мы к этому подходим. Это зависит от целей, которые он ставит.

• Если же процесс в зачаточном состоянии, его не имеет смысла описывать «как есть» детально, пооперационно. Давайте тогда мы будем делать инжиниринг, моделирование – соберем рабочую группу из заинтересованных лиц и будем вместе с использованием best practice сразу проектировать «как должно быть», и не тратить время на пооперационное описание «как есть».

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

Что делать, чтобы бизнес-процессы «как должно быть» жили дальше, и заказчик их сам поддерживал? Внедрять под них инструменты в системе?

Да. В компании от 200-300 человек имеет смысл начинать внедрять отдельные элементы управления процессами сразу – хотя бы в рамках системы менеджмента качества.

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

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

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

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

Когда я говорю: «Ставьте типовую коробку», я не имею в виду, что купили коробку, поставили, включились и пошли работать. Так тоже не получится.

Вы можете подготовить сквозные контрольные примеры на данных заказчика и вместе с заказчиком их разобрать: открываете, показываете и прямо в продукте начинаете что-то поднастраивать. Устраивает? Устраивает. Соответствует? Соответствует, запускаемся.

Что делать, если заказчик говорит: «Нам нужно, чтобы завтра уже все работало»?

Всегда есть объективные ограничения. Волшебной пилюли нет – 9 женщин за один месяц ребенка не рожают.

Если заказчик говорит: «Я хочу, чтобы завтра работало». Я говорю: «По моему опыту, проект внедрения даже типовой функциональности – анализ деятельности «как есть» займет столько-то месяцев, подготовка системы с минимальной кастомизацией – столько-то, перенос ваших начальных данных с выверкой – столько-то. Вы хотите завтра работать? Тогда типовую коробку ставьте и работайте, нет проблем. Не хотите? Тогда давайте находить какие-то варианты».

Возможно, не надо браться за проекты, которые обречены на провал, потому что заказчик настолько ригидный, что он не понимает и вас не слышит. Приходит к вам пациент, он говорит: «Я буду пить и курить, но я хочу быть здоровым». Вы говорите: «Перестань пить, перестань курить, веди здоровый образ жизни». А он: «Нет, но я хочу быть здоровым». Вы что будете делать? Ничего.

Любой проект автоматизации – это проект изменений. Любой проект изменений – это всегда совместная работа. Всегда те, кто делают, и те, с кем это делают – это единая команда. Если вы приходите к заказчику, который стоит в стороне и говорит: «Я ничего делать не буду, буду продолжать пить, курить, но сделайте мне хорошо», то подумайте, точно надо с ним работать или нет. Это звучит жестко. Но это помогает избежать ошибок.

Как в процессе обследования при сборе хронометража решается вопрос достоверности? Обмануть-то легко, а как потом оптимизировать то, что было неправильно обследовано?

Самое плохое в хронометраже – сделать анкету и сказать сотрудникам: «Записываете, что вы делали в течение дня», тогда ничего адекватного не получите, точно наврут.

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.