Меню
+7 (342) 211 43 53
Обратный звонок
Автоматизация и бизнес-процессы

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

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

Почему так получается? Какие проблемы стоят перед Исполнителем и Заказчиком? Попробуем разобраться, не претендуя на всеобъемлющую полноту.

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

Основные проблемы и задачи, требующие особого внимания:

  1. Отсутствие постановки задачи менеджмента на предприятии;
  2. Потребность в частичной или полной реорганизации структуры предприятия;
  3. Необходимость изменения технологии бизнеса в различных аспектах;
  4. Сопротивление сотрудников предприятия;
  5. Увеличение нагрузки на сотрудников в период внедрения системы;
  6. Потребность в формировании квалифицированной группы внедрения и сопровождения системы, а также в выборе сильного руководителя группы.
  7. Мифы.

Поговорим более подробно о некоторых из них.

Первая проблема. Проблема заказчика

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

  1. Автоматизировать или нет? Что в первую очередь?
  2. С кем? В какие сроки? За какие деньги?

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

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

Вторая проблема. Проблема исполнителя

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

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

Третья проблема. Миф о критической стоимости обновления (поддержки продукта) после адаптации продукта под нужды бизнеса.

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

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

Таким образом, на имеющиеся неоптимизированные процессы накладываются неконтролируемые изменения. Неконтролируемые в том смысле, что анализ такого влияния на текущие процессы не проводится. Какие будут последствия, мало кому известно.

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

Даже, если бизнес и готов поставить бизнес-цели перед автоматизацией, значительная часть консультантов по продукту все равно выведет Заказчика на вопрос «что вы хотите конкретно?». У функциональных участников различных процессов это называется сбором требований.

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

Вам абсолютно понятны Бизнес-требования, которые вы озвучили. Но разработанное на их основе Техническое задание, как правило, содержит предложенные программистами принципы организации обмена данными и перечень прочих доработок, которые делают продукт сложным для понимания. Приходится верить, что ваши требования учтены и включены в ТЗ, и что внесенные доработки решат поставленные бизнес-задачи.

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

Последствия для обеих сторон зачастую довольно неприятны.

Почти вся автоматизация, которая сейчас производится на свет – результат реализации примитивов/шаблонов. По крайней мере, такое впечатление создается.



Что делать?

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

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

Почему нельзя автоматизировать процессы «как есть»?

Процессы не соответствуют целям, это может произойти по нескольким причинам:

Перед тем, как инициировать проект по автоматизации, Заказчик должен решить для себя, что нужно (и нужно ли) автоматизировать. Выбрать области своей деятельности для автоматизации, исходя из тех или иных соображений, например:

Исходя из всего сказанного, проект автоматизации должен иметь бизнес-цель, которая вытекает из целей самого бизнеса. Цель автоматизации получается декомпозицией цели(ей) бизнеса до целей бизнес-процессов. Для этого необходимо построить дерево целей.

Первый шаг. Определить цель(и) и области автоматизации.

Если это уже проделано, то первая часть определена.

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

Второй шаг. Описание процессов «Как есть».

Зачем это делать?

Чтобы понять:

Третий шаг. Оптимизация процесса по целям.

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

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

Оно должно содержать:

Кто будет выполнять шаги 2-4?

  1. Собственными силами. Но в этом случае необходимообучение сотрудников, что, как правило, не гарантирует достижения цели.
  2. Силами внешних консультантов. На выходе вы получите продукт, но знания и навыки для дальнейшей работы нет. В следующий раз придется вновь обращаться к специалистам, а это не самый дешевый вид консалтинга.
  3. Силами внешних консультантов, но с привлечением на всех этапах ключевых для проекта сотрудников:

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

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

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

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

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

Реализация проекта - собственно внедрение - может проводится под патронажем IT службы Заказчика и непременном участии владельцев автоматизируемых бизнес-процессов.

21 июня 2018
Возврат к списку
Подпишитесь на наши новости
Обратный звонок