Блог Comindware
  1. Вы здесь:
  2. Comindware
  3. Библиотека Comindware
  4. Идеи
  5. В чем секрет успешного внедрения автоматизации бизнес-процессов?

В чем секрет успешного внедрения автоматизации бизнес-процессов?

74% компаний снизили затраты и увеличили производительность труда за счет автоматизации процессов, согласно исследованию Gartner (Critical Roles for Successful BPM Projects and Programs, Gartner, 2012).

Как же войти в эти 74% и какие ошибки сделали остальные 26%, которые не достигли эффекта?


Comindware banner

секрет успешного внедрения автоматизации бизнес-процессов

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

Если участвуют несколько квалифицированных людей, тогда лучше работает следующий подход:

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

На этапе «набросать процесс» важно определить состояние того, что требуется отслеживать. За изменением статуса какого объекта необходимо наблюдать? Например, если мы говорим о процессе продажи, то статусы каких объектов будем отслеживать – коммерческого предложения, сделки или договора? Чтобы разобраться в объектах, стоит определить какие данные необходимо собирать и какие отчеты нужно формировать. Например, если сделка одна, а договоров по одной сделке может быть несколько (товары, услуги, поддержка), и отчеты нужны и по состоянию (суммам, типам) договоров, и по самим сделкам (суммы, даты закрытия, вероятности), то стоит отслеживать 2 объекта – и сделки, и договоры по ним.

Например, в одном проекте нужно было отслеживать проведенные демонстрации продукта. Для расчета премий менеджерам необходимо было делить демонстрации по одной сделке на 1, 2, 3… — демонстраций могло быть несколько по одной сделке. Поэтому сделали 2 объекта – сделка и демонстрация по сделке.

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

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

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

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

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

Другой масштаб проекта – в процессе участвуют сотрудники разного уровня квалификации и разной степени вовлеченности, их много — десятки, сотни, тысячи. В этом случае больше внимания нужно уделять каждому этапу, каждой детали. Если в первом случае необходимые изменения можно обсудить с остальными участниками и легко изменить бизнес-процесс. Но в масштабном проекте нужно учесть множество деталей, поскольку очевидно, что стоимость изменения существенно выше, т.к. вовлечено большее количество людей, отчетов, данных, интеграций. Поэтому два важных дополнения к озвученному выше подходу – «набросать процесс» превращается в отдельный проект – необходимо проанализировать текущие процесс(ы) — «AS IS» и оптимизировать его (их) с учетом возможностей автоматизации – «TO BE». Описание бизнес-процессов для анализа делают в одной из подходящих (что подходит – отдельная тема) нотаций, например, BPMN, IDEF0, Cross Functional Flowchart и др. Второе дополнение – перед запуском процесса в эксплуатацию необходимо провести тщательную пилотную эксплуатацию на реальных данных с реальными пользователями – можно ограничить количеством документов, двумя филиалами и т.д. По итогам необходимо составить инструкции, а лучше — максимальное количество подсказок в самой BPM системе, чтобы сотрудник видел там всю необходимую для работы информацию.

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

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

  • В составе проектного комитета должны быть сотрудники с ролями – заказчик, менеджер проекта внедрения, исполнитель. Спонсора  можно привлекать в случае изменения бюджета проекта. Менеджер проект – это основной драйвер внедрения, он проводник решений, целей, он вовлекает других участников, организует решение возникающих проблем, лучших решений;
  • Создайте пилотную группу (если нельзя привлечь всех пользователей) из участников процесса всех уровней – руководителей, экспертов, исполнителей;
  • Организуйте несколько встреч – первую встречу важно провести перед началом проекта — расскажите пилотной группе цели, ожидаемые изменения, задачи, роли; ответьте на возражения; выделите тех, кто является приверженцем проекта – их можно будет активно привлекать; и тех, кто негативно, но конструктивно настроен – от них можно получать полезную критику. Вторую встречу лучше провести перед запуском тестовой эксплуатации. Третью — перед запуском в промышленную эксплуатацию, и четвертую — через месяц, чтобы подвести итоги и сравнить, как было до и как стало после; что еще можно улучшить.

Успешных внедрений!



Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Понравилась статья?

Поделитесь ссылкой

Опубликовано:  в разделе Идеи, Мир проектов