Книга: Введение в управление проектами внедрения ERP-систем
Назад: 6.4.4.BPMN
Дальше: 6.5.Прототип и его демонстрация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Назад: 6.4.4.BPMN
Дальше: 6.5.Прототип и его демонстрация