Бизнес план по внедрению информационной системы на предприятии

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

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

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

Для себя все проблемы, препятствующие успешной реализации проекта я делю на три категории:

1. Политические, вызванные несоответствием заявленных целей реализации проекта с внутренними ожиданиями участников проекта
2. Функциональные, вызванные недостатком компетенций участников проекта
3. Технологические, вызванные недооценкой требуемых ресурсов, времени

Это довольно укрупненно и условно, но лично мне помогает при ранжировании рисков сформировать оценку вероятности успешного внедрения системы.

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

1. Обследование предприятия, описание бизнес-процессов «как есть», «как будет».
2. Создание модели информационной системы.
3. Разработка и реализация ТЗ.
4. Тестовая эксплуатация.
5. Опытно-промышленная эксплуатация.

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

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

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

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

Итак, начну.

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

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

Другой вопрос, что эти устоявшиеся бизнес-процесс неоптимальны, избыточны, а иногда в них ещё и отсутствует какая-либо ценность как для бизнеса, так и для участника бизнес-процесса. Как пример, это формирование какой-либо управленческой отчетности, про назначение которой все уже забыли, анализом содержания которой никто не занимается и необходимость создания этой отчетности аргументируется на уровне «Мария Ивановна всегда просит это делать, а зачем, да бог её знает, спросите у неё».

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

На практике же все выглядит гораздо плачевнее. К изменению бизнес-процессов, даже самых элементарных, не готовы рядовые исполнители. Может это лично моя неудачная практика работы на пром. предприятиях, может это реально существующая тенденция, но не ждите, что фразой «теперь тебе не нужно будет нести расходный ордер на согласование ногами за 3 километра, а можно сделать автоматом в системе за 3 секунды» вы получите восторг в ответ. Рядовой исполнитель, чья работа-то и заключалась 60% времени в беге с документами тут же решит, что его сократят, навалят ему работы, в которой он не соображает либо снизят ему зарплату. Логика в его соображениях не всегда присутствует, но сопротивляемость изменениям рядовой сотрудник может оказать вполне явную. Причем как на этапе сбора требований к системе, когда он будет доказывать ценность именно беготни с бумажками («А МихалКузмич из отдела бюджетирования головной организации сказал, что принимают от нас только скан документа со всеми подписями»), так и на этапе эксплуатации системы, когда он просто втупую будет распечатывать ордера из старой системы и носить их ногами («а мне никто не говорил, что новая система уже работает», «ой, да мне ногами быстрее», «а я отправила в этой вашей системе, а там никто не ответил» и т.д.).

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

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

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

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

Что можно предпринять для наиболее продуктивного изменения бизнес-процессов?

1. Моделировать бизнес-процессы «как должно быть» из соображений целесообразности бизнес-процесса, а ресурсы рассчитывать уже на основании принятой схемы бизнес-процесса. С одной стороны, как бы это ни было тяжело, но планировать ресурсы надо с учетом существующих реалий. Увы, но в рабочем дне 8 часов и сотрудник не сможет сделать больше того, что он может сделать. Если по факту целевого бизнес-процесса сотрудник отдела продаж сможет сделать только одно коммерческое предложение, то он сделает только одно. Даже если на бумаге вы зафиксируете 10 КП в день.

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

2. На этапе моделирования детальных подпроцессов и бизнес-процесса в целом производить оценку требований по доступности ресурсов и плановое время исполнения каждой операции. Владелец бизнес-процесса должен подтвердить ресурсный план ещё на этой стадии и отвечать за его исполнение. Иначе, как я уже говорил выше, недостаток или неготовность ресурсов выявится довольно поздно и станет веской причиной приостановить проект. А приостановленные проекты, как правило, умирают в забытии.
3. Моделируемые и реализуемые бизнес-процессы должны подвергаться постоянному аудиту. Как на скорость выполнения экземпляров бизнес-процессов, так и на выявление причин их отклонения. Желательно, чтобы на этапе реализации проекта был выделен не только владелец каждого бизнес-процесса, но и его аудитор. Это может быть вновь созданная служба внутреннего аудита, либо уже имеющаяся служба. Не стоит ждать, что аудитор бизнес-процесса, назначенный внутри подразделения, будет выполнять эти функции успешно, да ещё и если эта функция придана ему «в нагрузку» к уже имеющимся задачам. Есть великий соблазн не распылять ресурсы и поступить именно так. Но нужно понимать, что в таком случае аудитор не будет заинтересован в выявлении отклонений внутри своего подразделения и система внутреннего аудита в таком случае будет довольно быстро похоронена. Менеджер, у которого в плане стоит 10 КП в день и он его еле-еле исполняет не пойдет за пять минут до конца рабочего дня по другим менеджерам проверять, а правильно ли они составили КП, а отправили ли они все КП на согласование руководителю, а не нарушили ли они сроки предоставления обратной связи клиенту.
4. Служба внутреннего аудита должна иметь инструменты для его проведения. Это могут быть и системы контроля исполнительской дисциплины внутри ERP-системы, так и отдельные системы моделирования бизнес-процессов. Но реализация этого функционала должна быть заложена изначально при проектировании системы. Аудит бизнес-процессов на этапе тестовой и опытно-промышленной эксплуатации системы должен проводиться в постоянном режиме. Аудитор бизнес-процессов должен иметь эту задачу как ключевую для своих функциональных обязанностей, уметь не только выявлять отклонения, но и находить их причины и разрабатывать мероприятия по их устранению.
5. Любой вновь выявленный подпроцесс в ходе эксплуатации системы должен пройти регламентацию, даже если он целиком покрывается ERP-системой, прост и понятен «даже дураку». Чем меньше разночтений в поведении системы, тем больше устойчивость самой системы.
6. В KPI владельцев процессов должны быть указаны результаты периодического аудита бизнес-процессов. Это помимо KPI по достижению целей проекта, выполнению планов по проекту и т.д.

Резюме: думаю, что проект по внедрению ERP-системы будет иметь гораздо больше шансов на успех, если все участники проекта со стороны заказчика будут разделять тезис, что информационная система служит для автоматизации СУЩЕСТВУЮЩИХ бизнес-процессов, готова их структурировать, раскладывать информацию по полочкам, готовить аналитику, но при этом не является заменой мозгам исполнителей и не будет палочкой-выручалочкой, если сам менеджмент предприятия не готов бороться с существующим хаосом.