Введение в управление проектами внедрения ERP-систем

6.4.5.Особенности описания бизнес-процессов

Рассмотрим некоторые определения для полноты понимания описания бизнес-процессов:

-Процесс – набор взаимосвязанных и взаимодействующих операций (действий), которые преобразуют входы в выходы.

-Бизнес-процесс – периодически повторяющаяся часть деятельности предприятия, отвечающая следующим критериям:

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

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

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

Шаги подготовки схем описания бизнес-процессов:

  • Готовим общую схему. Ставим точку начала и конца и заполняем шаги между ними.
  • Детализируем схему в диаграмму (то есть в итоговую схему в требуемой нотации), попутно разбивая на подсхемы, и понимаем, что не все понимаем сами.
  • Просим дополнительную информацию для анализа.
  • Рисуем дальше диаграммы. Могут появиться альтернативные окончания процессов, все уточняется по ходу наращивания детализации.
  • Гнаться за максимальной детализацией на схеме смысла нет, схема может превратиться в нечитабельную паутину из стрелок, используем группировку в подпроцессы.
  • При завершении диаграмм начинаем описывать бизнес-процессы словами. Описывать диаграммы по неясным из схем вещам. Может быть схема совсем без описания, когда все ясно без пояснений. Дословное описание схемы делать не нужно, это не имеет смысла, только перегрузит итоговый документ.

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

  • Что на выходе?
  • Что на входе?
  • Кто это делает?
  • Исполнитель или система уже располагает информацией для этого действия на этом шаге?
  • Что является причиной (управленческим воздействием) для этого действия? И так далее.

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

Обязательно ли нужно описывать бизнес-процессы «как есть»? С одной стороны, для проекта внедрения нужна целевая схема «как будет», и можно было бы сразу рисовать ее. Но если предполагается реинжиниринг процессов, то для понимания заказчиком процесса перехода из состояния «было» в «будет» схемы «как есть» будут необходимы. Также отметим, что со схем «как есть» проще начать проектирование и перейти потом к подготовке целевых схем за счет моделирования на готовых схемах новых их состояний (перетасовкой элементов).

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

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

Рассмотрим критерии значимости (то есть нужно ли их описывать детально) бизнес-процессов для внедрения КИС:

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

Цели описания бизнес процессов – это найти ответы на вопросы:

  • Какая цель данного бизнес-процесса, его место и роль в общих задачах (процессах) компании?
  • Какие функции и в какой последовательности выполняются в рамках процесса?
  • Кто является ответственным за выполнение каждой из функций?
  • Условия начала выполнения каждой функции, какие события инициализируют выполнения функции?
  • Документы и данные, необходимые для выполнения бизнес-процесса, функций и их источники?
  • Документы, создаваемые в результате выполнения бизнес-процесса, и их получатели?
  • Какие программные и аппаратные комплексы задействованы, в каких операциях?
  • Что является результатом работы, какие проблемы возникают при выполнении работы?

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

Необходимо в фазе анализа сразу выявить требования к разграничениям прав доступа пользователей к данным и функциональности КИС:

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

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

В завершение раздела про бизнес-процессы и важность их понимания до начала работ по внедрению – небольшая история про «забытый» отдел. Автор лично встречал ситуацию почти по Михаилу Задорнову с его рассказом «Девятый вагон» и фразой: «Мой вагон пустой!» А именно: идет вовсю запуск системы, перевод логистики со старой системы в ERP, все уже спроектировано, пользователи обучены, отказ от прошлых систем, полет нормальный. Через неделю выясняется, что ключевые сотрудники заказчика забыли включить в границы проекта целый бизнес-процесс группы из 5 сотрудников, которые все еще продолжали работать в старой системе, сидели в отдельной комнате, ажиотаж внедрения не видели, обучение не проходили, в ERP их никто не переводил. И забеспокоились они сами, когда у них закрылся список отработки заявок в старой системе, а новые перестали появляться, стало пусто и нечего отрабатывать.

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

Показать оглавление

Комментариев: 0

Оставить комментарий