Узнайте нужен ли в Вашей компании Service Desk

8 (495) 726-15-52

Всегда ли плоха «лоскутная автоматизация»?

Публикация в журнале CIO, «Директор информационной службы» , № 10, 2011.

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

Необходимо менять (и срочно) именно этот кусок. Однако (что вполне естественно) изменение это части бизнеса в дальнейшем приведет к реструктуризации большого количества других процессов.

Как проводить автоматизацию в такой динамично развивающейся бизнес среде?

Большое внедрение

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

И, как правило, запуск в промышленную эксплуатацию такой системы означает начало  работы всей компании по совершенно новой модели.

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

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

А оно нам надо?

По данные GartnerGroupдо 70% внедрений ERPсистем заканчиваются провалом. Процент неудачных внедрений в России еще выше. С чем это связано? Причин, как правило, бывает несколько: недостаточная зрелость процессов компании, нечеткое представление о необходимых изменениях, невозможность торможения  развития бизнеса ради внедрения информационной системы.

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

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

Существует понятие – готовность компании ко внедрению. Как определить ее наличие и на какие грабли может наступить компания не вполне готовая к ней или не имеющая опыта полномасштабной автоматизации?

 Рассмотрим основные проблемы.

Архитектура и Архитекторы

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

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

Через полгода руководство компании высказало пожелания о дальнейшем развитии в этом направлении. Но это оказалось невозможным, в силу как раз архитектурных ограничений. Система не была распределенной, не масштабировалась и не могла расширяться так, как необходимо было бизнесу. Рывок, который сделал бизнес и на который он рассчитывал – продлился всего полгода. А дальше – возможности системы были исчерпаны.

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

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

К пуговицам претензий нет?

Помимо рисков технических и архитектурных ограничений существует еще один, связанный с человеческим фактором. Процессы спроектированы , автоматизированы и внедрены, но наступает день старта системы и начинается кошмар – все не работает или работает не так как надо, но не по техническим причинам, а по причине не готовности персонала. Система работает корректно, но результат не адекватен ожиданиям. А разработчики просто пожимают плечами и показывают подписанное вами техническое задание. "К пуговицам у вас претензий нет? Мы отвечали за пуговицы, а не за ваш бизнес и за ваших сотрудников".  

Привязка к конкретному исполнителю

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

Конкретное решение конкретной компании, как правило, сажает клиента «на иглу», заставляя работать именно с этими исполнителями, и не позволит в будущем их поменять. Что из этого может следовать:

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

«Деньги на ветер»

Бывает так, что  мы оплачиваем какие-то работы, результат которых не будет востребован..

Почему так происходит?

  • Решение, которое принимали – устарело
  • Поменялась ситуация на рынке
  • Компания оказалась не готова к внедрению.

Могут ли в этой ситуации быть положительные моменты?

Оказывается - могут.

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

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

Во всем, кроме лицензий.

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

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

Что делать?

Как избежать подобных ситуаций?

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

Эволюция, а не революция

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

При этом процесс развития становится более непрерывным с минимальными рисками.

Разве такое возможно? Оказывается – да и в этом нет ничего нового.

Как всегда – новое это хорошо забытое старое.

Есть слона по кускам

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

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

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

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

Разумеется, это не выглядит так красиво, как при внедрении одного большого и стройного решения. Но, что вам нужнее - красота или жизнеспособность?

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

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